-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debloat the library #8
Comments
I totally agree. I'm excited to use this but as of now it's going way over my performance budget. |
I agree wholeheartedly; the fat shall be trimmed. |
I opened a PR to fix this issue. |
Hello everyone ! I have been watching this repo and am currently contemplating using it with rematch for a custom persisted state (there have been issues with redux-persist on android) and I must say that this looks very promising. I am not sure if this will be of much help - haven't studied the code enough to understand its architecture fully. -- but that being said -- Perhaps there is a way to prioritize client delivery where say the IronDB LocalStorage Primary mechanism is pushed/delivered as a critical path resource, to the client, and subsequently there after IronDB boots up client side and proceeds to internally Lazy Load its other secondary and tertiary mechanisms/non critical-functionality. The inspiration comes from a framework-less application that I am currently building - consisting of entirely LitElement and Custom Web Components and the philosophy has lead to very small builds. (our entire app is less than 31K with feature parity ~80% that of Slack) From a perspective of use case, the only critical functionality that I would need on application boot-up would be "Getting" data from Local Storage for the sake of redux rehydration. Other than that, "Setting" data, data validation, and multiple storages, could be "import(../Non-Critical-Functionality)" after the fact. Please let me know some thoughts on this idea and maybe there is a way that I can get involved. This is very exciting. All the best, |
@T-Knott-Mesh I'm afraid I don't understand your question. Please open a new issue so your question gets proper attention and isn't |
IronDB v1.0.0 hit the gym again. I replaced lodash[-es] entirely. Minified Closing this issue; no large, low hanging footprint optimizations remain. Huge thank you @bm-stschneider, @kr05, @jcar787, and @ecwyne for your input and |
103kb gzipped for simple redundance of localstorage and cookies is pretty unacceptable.
Try to tree shake lodash for example or do it manual via https://www.npmjs.com/search?q=keywords:lodash-modularized
The text was updated successfully, but these errors were encountered: