I have had no issues with the aurelia store. Then, I did build for prod. The store no longer stores the data properly. The data fields are being stored in locations that do not match what is in the “state.js” file. Data is appearing at site start up that does match the “initialState” variable. Why would there be a difference between dev and prod in the way the store behaves?
1 Like
There shouldn’t be. Maybe the issue is somewhere else. Could you help sharing a reproduction repository?
Sorry, I can’t share the code, but it seems to me it is related to a difference in how the framework builds the app in dev verses prod. Is there a build process in prod, that is not performed during a dev build, that could potentially affect the store? There is no source code difference between dev and prod. The only thing I do is - “au build --env prod” instead of “au build”. The state data itself is JSON.
1 Like
A rule of thumb is when you get an error, paste it so folks can get your points faster. So, please give some more details about the error you encountered with your production build. For the issue itself, others have been using it for production quite a long time and haven’t gotten any issues with it, so I think there’s some slightly different configuration that caused the issue.
I am not getting an error in the console. The Store just doesn’t work. The data seems to be corrupted in some way.
I’ve been able to narrow it down to a problem introduced as a result of minifying. If I do a prod build without minifying, the store works. if I do a build with minifying, the store stops working properly (no error, just corrupted data).
So, I can at least do a prod build with no minification, but it would be nice to be able to get the benefit of minifying as well.
So, it may not be the store itself, but something happening to the code that reads and writes to the store when minified.
1 Like
Are you using static view model reference in anyway? Be careful with (1) webpack export name mangling, (2) class name minification