What exactly is "experimental" about array methods?

[talha-asad]

I really like your package and use it alot. I have never had any issues with the array methods.

However I have had issues where I had to forceInvalidations for no apparent reason. Are there edge cases where autoruns and Trackers aren't recomputated when a key in ReactiveObj change?

[xamfoo]

Array methods are experimental in the sense I'm still leaving room to change how the API is called in future versions. Particularly, I was thinking about support for Map, Set, String, other object types and dealing method name collisions. Maybe I should be more explicit about it.

However I have had issues where I had to forceInvalidations for no apparent reason. Are there edge cases where autoruns and Trackers aren't recomputated when a key in ReactiveObj change?

I'm expecting forceInvalidations only to be used when mutating values in stored in ReactiveObj directly. I'll be happy to fix edge cases that you encountered.

[talha-asad]

Thanks alot for the explanation. So far there has been just one location where i had to forceInvalidation to get the changes to reflect and the autoruns to retrigger. I have no understanding of why it is needed here, thats why i asked.

So the use-case is like this, On the click event of a button, i do a forEach loop on an array and then inside that i have another async call, in which i push a value to nested level array. I have tried doing it, by directly fetching and mutating, fetching, doing a push and then explicitly setting the key to the mutated array. The only thing that works is calling forceInvalidation. I thought it maybe related to 3 level deep function mutation, however that wasn't the case when i tried a much simpler use case on the browser console for the same key.

The code is somewhat like this (removed some extra parts):

        self.$('button.upload.images').click(function(e) {
          var uploadBtnEl = $(this),
                filesToUpload = campaignImagesDropzone.getAcceptedFiles();
          self.viewData.set('misc.uploadingImages', filesToUpload.length);
          filesToUpload.forEach(function(file) {
            file.status = Dropzone.UPLOADING;
            var fsFile = new FS.File(file);
            fsFile.owner = Meteor.userId();
            FSCampaignMedia.insert(fsFile, function(err, fileObj) {
              if (err) return campaignImagesDropzone.emit('error', file, 'failed to upload: ' + err);
              file.status = Dropzone.SUCCESS;
              file.upload.progress = 100;
              file.upload.bytesSent = file.upload.total;
              file.fsRef = fileObj;

              self.viewData.push('misc.uploadedImageIds', fileObj._id);
              self.viewData.forceInvalidate('misc.uploadedImageIds');
              self.viewData.set('misc.uploadedImages', self.viewData.get('misc.uploadedImages') + 1);
            });
          });
        });

self.viewData is a ReactiveObject here. If i don't forceInvalidation but get the key on the browser console it gives the correct updated value, however the autoruns aren't retriggered.

[xamfoo]

How is misc.uploadedImageIds accessed reactively?

Increment operation can also be written as self.viewData.update('misc.uploadedImages', function (v) { return v + 1; });

[talha-asad]

misc.uploadedImageIds is being accessed reactively through a Blaze helper:

  viewData(key) {
    if (key)
      return Template.instance().viewData.get(key);
    return Template.instance().viewData.get();
  }

I use this helper like: {{viewData 'misc.uploadedImageIds'}}

I didn't know i could give a function as a second parameter, will try that.

[xamfoo]

I see. I think a reproduction could be needed to fix this. Is your code open sourced?

[talha-asad]

No our source code isn't open sourced :(

I'll try and come up with a simpler reproduction so we can nail this. Thanks.