nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

FeatureLayer.historicMoment is ignored when applied several times

Frédéric_ALBERT

Hello,

We've encountered an issue when upgrading our solution from API 4.16 to 4.19.

When editing a utility network feature layer (therefore branch versioned), we do use the historicMoment property feature layers to reflect the user edit stack (edits, undo/redos, commit or cancel).
At 4.16 this was working like a charm.
At 4.19 (and I tried also 4.17 and 4.18), the property setting is ignored after the first update. The first update (from undefined to a Date) is acknowledged, all subsequent updates to historicMoment are just ignored when the layer is querying the server.

Is anyone having the same issue ? Is there any other other workflow to make sure a FeatureLayer is correctly reading the updated branch moment ?

Example:

Phase 1: New version, default moment. Layer is querying server without mentioning historicMoment
Phase 2: layer.historicMoment = 1619437065322. Layer is querying server with updated historicMoment
Phase 3: layer.historicMoment = 1619437085523. Layer keeps querying server with old previous historicMoment.

historicMoment-stage-2.PNG

MapProperties.png

Finde mehr Beiträge mit dem Tag

Accepted answers

UndralBatsukh

@JohnGrayson you are absolutely right! It did not cross my mind. @Frédéric_ALBERT if you migrate to 4.19 then you use interceptor in your application. You could do the following and I verified that it is working for me:

const interceptor = {
  urls: [
    "yourServiceURL",
  ],
  before({ url, requestOptions }) {
    requestOptions.query.token = token;
    if (editMoment){
      // where editMoment is updated after applyEdits operation
      requestOptions.query.historicMoment = editMoment.getTime();
    }
  }
};
esriConfig.request.interceptors.push(interceptor);

-Undral

Frédéric_ALBERT

I guess it can be used in many ways, but in my case I used it to provide an undo/redo stack experience while editing utility networks in child branch. Additionnaly child branches also provide different edit sessions at the same time, short or long.
In the end it is very versatile and poweful and implementation can be as complex as required by your user stories.

All comments

UndralBatsukh

Hi there,

Is it possible for you post how and when you are setting your historicMoment parameters? Basically I am looking for a code snippet where I can reproduce the behavior you are running into so that we can fix the issue.

I just ran a very simple test and seems like historic moments are being honored. In this example, I am starting with a specified historic moment and is working.

var featureLayer = new FeatureLayer({
  url: "serviceUrl",
  outFields: ["*"],
  gdbVersion: "yourVersion",
  historicMoment: new Date(1619458348280)
});

featureLayer.on("edits", function(result){
  console.log("edit result", result);
  var query = featureLayer.createQuery();
  console.log("query", query.historicMoment, featureLayer.historicMoment);
  featureLayer.queryFeatureCount().then(function(results){
   console.log("query", results)
  });
});

Thanks,

-Undral

Frédéric_ALBERT

I got you a codepen ready to reproduce the issue:

Unfortunately my server is internal, so you'll have to change some url and template to have it working.
It works with a branch versionned feature point layer.
The workflow is the following:

Load the map and the branch versionned feature layer
Collect guids regarding edited and default versions for the feature layer. Generate guid for the session.

Then all requests are done through a direct fetch against REST API:

StartReading, StartEditing, ApplyEdits
ApplyEdits will return an editMoment
This editMoment is applied to FeatureLayer.historicMoment property to update the display.

At 4.19, you can create a point, you'll see it. The second point, you will not see it: historicMoment is not accounted for by the feature layer.
At 4.16, the sample works as expected.

It looks like at FeatureLayer.historicMoment does not allow a second mutation of historicMoment property.

UndralBatsukh

Thank you so much for the reproducible case. It was really easy to set it up with our test service. So I was able to reproduce the problem you described. As you have described, api queries are not honoring the FeatureLayer.historicMoment after its initial settings. Subsequent queries are being made with the initial historic moment. I have created an issue for this and do not have a workaround for this. I will be sure to update you once we fix the issue.

Thank you so much for bringing this issue to our attention.

-Undral

JohnGrayson

@UndralBatsukh: not sure, but would a requestInterceptor help for this use-case where we inject the historicMoment parameter if it's missing?

UndralBatsukh

const interceptor = {
  urls: [
    "yourServiceURL",
  ],
  before({ url, requestOptions }) {
    requestOptions.query.token = token;
    if (editMoment){
      // where editMoment is updated after applyEdits operation
      requestOptions.query.historicMoment = editMoment.getTime();
    }
  }
};
esriConfig.request.interceptors.push(interceptor);

-Undral

Frédéric_ALBERT

Using the interceptor as suggested works like a charm.
I updated the pen to implement the workaround and upgraded to 4.19 ESM.
I hope this will get fixed soon.
Thanks a lot.

UndralBatsukh

Hi there,

I just want to let you know that we fixed this issue at the JS API version 4.20. The version 4.20 will be released at the end of June (2021).

Thanks,

-Undral

HéctorMeléndez

Does the historicMoment work to undo/redo in a child branch or only when editing the default branch?

Frédéric_ALBERT

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.