@ramblurr have a look at #rum
Isn't rum a frontend lib? This particular use case has nothing to do with rendering ui, it's all just data processing.
Fulcro is not necessarily pathom, although pathom was born from it. Fulcro parses the eql query that your view components compose to and helps with (de)normalizing a data into your local db.
Yes it is a front-end lib, sorry misinterpreted that your game logic was tied to UI somehow
No worries, I see the value of EQL when it comes to rendering UIs, but in this case it is just data processing on inter-related data, and need an expressive way to query and change the data
as for migration, in general I see the recommendation that you only add to schemas, and use namespacing to avoid api breakage.
in that case datalog sounds good to me 🙂
pathom might still offer value to you, it also deals with mutations
I found an https://github.com/mpdairy/posh/pull/18/files#diff-04e213e7f0ad90afa2c9a82635644f5fR8 to Posh that has some simple logic for validating and applying datascript schema migrations, refactored it a bit to not care about datomic, and it seems to work in my limited testing
So it seems I could use datascript for this after all and be able to alter the schema as I go
when still developing something I'd break the schema all the time, part of the process. Datascript is supposed to be "lightweight" in the sense that you can rebuild it with a different schema quite easily.
in case you never saw it before: https://www.youtube.com/watch?v=oyLBGkS5ICk I think the point of accretion in software is quite enlightening.
Yup, that's a classic. Been awhile since I've watched it
I'm currrently building an app that lets you opt into different kinds of notifications when you make a certain request. For example, you can be notified via email or a message on Discord. Now I'm trying to figure out how to model this. I have a request entity, but a fixed attribute for each notification method makes this very static and hard to query if everything is optional
I've been thinking about making a separate "notification" entity or something but this seems like a very SQL-style approach, is there something else I could do?