Clojurians Log v2

@ethangracer: So this seems to be working https://gist.github.com/currentoor/f9fbc881b489718630f8ee36d6aaad75

I ended up not using the decorator pattern, just regular recursion.

If I understand your usecase, this might work for you as well. Also I'll benchmark it but I doubt it has too much of a performance penalty, especially given the level of extensibility and reuse it offers.

We'll probably move forward with this approach. It might be a little too custom-DSL-y for untangled. I'm happy to contribute it if there's interest? I promise my feelings won't be hurt if you guys don't want it!

@currentoor: I’ll play around with it for sure -- ultimately it’s @tony.kay’s decision to merge it, regardless we very much appreciate the work and thought that you and the rest of your team are investing in Untangled!

No worries! We're happy to do what we can. We get a ton of value out of untangled.

@ethangracer: thx for your answers! the problem i see with this approach is when i have 2 autocomplete components on the screen (one for clients and one for products for example) and the user is changing the components faster than the server can respond and so the data gets merged in the wrong place because the params are overwritten by the other component

@w1ng: no problem! so with further thought I think I may still be misunderstanding. You have one autocomplete component class, but each component instance should have a different ident. So when you load data from the server, the data should be merged back to the location in app-state specified by that ident. Are you using different idents for the two autocomplete components that you mentioned?

is untangled-datomic schema documented anywhere yet? it looks pretty much like yuppiechef/datomic-schema; is that a safe guideline?

@curtosis: exactly...we added some extensions

but those extensions are experimental..we're not even sure we want them

they were attempts at a general typing system with referential integrity checks

I nosed around in the code and saw some of that, yeah.

I had an apparently-justified raised-eyebrow response ... "this seems like it might be useful.... but maybe not...?" 😉

right...it is less useful just from the fact that it is "advisory". You have to always use vtransact instead of transact

and any "run-time" by-hand changes to the db are not enforced

so, your data can still be made "incorrect"

...which may be ok, since it feels like you have to be a little more thoughtful anyway about where you want to apply "invariants" in (idiomatic) datomic.

may be ok, that is. As I said, thought-provoking. And thoughts I don't have time for on this project yet. 😉

I'm still in the land of datomic-schema-to-ui-query-schema impedance matching.

@ethangracer: I haven't used indents, but I think thats the right way to do this thx !