I just released Elm Store, a system to store items by ID with support for multiple secondary keys (ie. indices). It is type-safe in the sense that one can only use an index if it has been configured.
I am thinking of adding more index/constraint options, better support for server-generated IDs or even some relational logic between several stores.
What do you think ? Is it useful to you ? Over-engineered for frontend maybe ?
I am working on an offline-first app. It contains “documents” with a machine ID and a human-friendly name. Both IDs and names need to be unique and I need to retrieve documents by both, depending on the case.
Usually generating ID and ensuring secondary keys uniqueness would be done server-side by the DB. Here I need to do it client-side since the app is offline-first (ie. it would work without internet connectivity).
At first I wrote some custom code for this, then I thought generalizing this in a type-safe way would be a nice challenge. Hence this lib.
Aside from this use case, I have had the feeling several times before that some kind of lightweight client-side relational DB could be useful (ala sql.js, but in pure Elm). So I am temped to push the project further in this direction. However I don’t really have a concrete use case for this right now so it feels to me a bit like engineering for the sake of engineering… which is fun but also wasteful.
Indices are implemented as Dict String (Id value) internally to provide O(ln(n)) access time. This requires to convert the value you want to index to String. On the other hand, it allows for case-insensitive indices (and basically indexing and setting constraints on any derived value).
I guess I could use comparable keys instead of String, but I am not sure to see the benefit?