FeatureLayer.historicMoment is ignored when applied several times

4486
9
Jump to solution
04-26-2021 05:58 AM
Frédéric_ALBERT
New Contributor II

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.

0 Kudos
2 Solutions

Accepted Solutions
UndralBatsukh
Esri Regular Contributor

@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

View solution in original post

0 Kudos
Frédéric_ALBERT
New Contributor II

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.

View solution in original post

9 Replies
UndralBatsukh
Esri Regular Contributor

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

0 Kudos
Frédéric_ALBERT
New Contributor II

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.

0 Kudos
UndralBatsukh
Esri Regular Contributor

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

0 Kudos
JohnGrayson
Esri Regular Contributor

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

0 Kudos
UndralBatsukh
Esri Regular Contributor

@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

0 Kudos
Frédéric_ALBERT
New Contributor II

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.

0 Kudos
UndralBatsukh
Esri Regular Contributor

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

0 Kudos
HéctorMeléndez
Esri Contributor

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

0 Kudos
Frédéric_ALBERT
New Contributor II

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.