meteor-fast-render
meteor-fast-render copied to clipboard
Fast render reinit will only load one document per collection...
When I disconnect and then reconnect Meteor from the client, minimongo gets cleared upon reconnect. This is because Meteor tries to resume any subscriptions and since I am using fast render, the client does not subscribe to subscriptions. Thus minimongo gets cleared.
But the data is still in the head of the document because of fast render.
When I call
InjectData.getData('fast-render-data', function(payload) {
FastRender.init(payload);
});
It only reloads one document per collection. Why is this? I need to reload minimongo with all fast render data.
This is how I am using fast render
if (Meteor.isServer) {
FastRender.onAllRoutes(function(path) {
this.subscribe('displayModels');
this.subscribe('selectionRules');
this.subscribe('models');
this.subscribe('accessories');
this.subscribe('accessoryCategories');
this.subscribe('modelSpecifications');
});
FastRender.route('/build/:templateId', function(params) {
this.subscribe('modelTemplate', params.templateId);
this.subscribe('packageTemplate', params.templateId);
});
}
How can I reload minimongo with all fast render data?
Also, something else weird about the payload, is that the _id key is missing from all documents.
I noticed this issue as well. However It only popped up when I pushed to production. So it has to have something to do with the minification. Probably the miniification messes up the way fast-renderer accesses the mongo collection. I will look into this more tomorrow.
@sferoze I haven't played with FR and reconnects yet, can you provide a demo app? Also, the _id missing thing is something I have noticed as well, but for me the _id comes in a different part of the payload array, and they are all merged down properly (somehow, I really dont know whats going on here).
I have confirmed that by removing the 'standard-minifier-js' package an doing a production build that the fast render works again.
Interesting, do you know what version of the package you were using?
so I have figured out a work around, but its not pull request-able. I have switched to this minifier "abernix:standard-minifier-js 2.1.0 " (although you can probably do this with the standard-minifier) and then did an over-ride on the minifier options inside the package itself "abernix_minifier.js"
var uglifyResult = uglify.minify(source,
mangle: {
reserved: ['Meteor._localStorage.getItem','_localStorage.getItem',
'_localStorage', '_livedata_data',
'connection._livedata_data','Meteor.connection._livedata_data', 'Meteor.connection._send','connection._send', '_send']
},
compress: {
drop_debugger: false,
unused: false,
dead_code: false
}
});
as you can see I added mangle reserved key words.
It boils down to the fact that they dont have a way to specify options to the minifier/mangle yet in Meteor. I guess unless you can import the meteor packages into the closure the mangler wont know how to link the parameters.
useful links mangler options https://github.com/mishoo/UglifyJS2 line I modified in (standard minifier) https://github.com/meteor/meteor/blob/devel/packages/minifier-js/minifier.js#L10
to save everyone time I tired this package with is supposed to allow options to be added to the minifier. It doesnt work :(
qqqry:uglifyjs
Thanks for the solution @jerradpatch. Hey @benjamn, is there any chance of allowing us to specify reserved keywords to standard-minifier-js? Or perhaps adding @jerradpatch's workaround to the defaults?
Unfortunately, I didn't see a meteor supported way of specifying passing options to the std minifier :(
Sent from my iPhone
On Aug 11, 2017, at 7:21 PM, Andrew Becker [email protected] wrote:
Thanks for the solution @jerradpatch. Hey @benjamn, is there any chance of allowing us to specify reserved keywords to standard-minifier-js? Or perhaps adding @jerradpatch's workaround to the defaults?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I had an issue where refreshing a particular route caused my production server to send an error "incomplete response received from application" which I think means the app crashed. On my local machine there was no problem, and it only occurred on reload, not when I navigated to that route. It seemed to be associated with a check failing in my publish function because of an empty object {} being passed in by fastrender. Because it only happened on the production server I guessed it was a minifier problem similar to the one in this thread.
@jerradpatch's workaround seems to have helped a lot with this. But it took me a day or two to find this thread and the workaround. If there is really no way to fix this in fastrender, then the workaround maybe should be part of the README?