Debloat the library about immortaldb HOT 8 CLOSED

I agree wholeheartedly; the fat shall be trimmed.

from immortaldb.

IronDB hit the gym: with @jcar787's PR #11, iron-db.min.js bundle size is now
down to 23kB.

More fat remains to be trimmed.

from immortaldb.

https://bundlephobia.com/result?p=iron-db

from immortaldb.

IronDB v1.0.0 hit the gym again. I replaced lodash[-es] entirely. Minified
bundle down to 5kB. Minified + gzipped down to 2kB.

Closing this issue; no large, low hanging footprint optimizations remain.

Huge thank you @bm-stschneider, @kr05, @jcar787, and @ecwyne for your input and
help. Don't hesitate to let me know if there's anything else I can do for you.

from immortaldb.

I totally agree. I'm excited to use this but as of now it's going way over my performance budget.

from immortaldb.

I opened a PR to fix this issue.
https://github.com/gruns/irondb/pull/11

from immortaldb.

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,
-Tsavo

from immortaldb.

@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
mistakenly amalgamated into this issue.

from immortaldb.