Fork me on GitHub
#untangled
<
2017-04-10
>
jonystorm14:04:33

Hi, has anybody worked on implementing datascript on untangled?

gardnervickers14:04:46

@jonystorm I don’t think so, Untangled is pretty coupled to the default Om.Next db format by design. Switching to Datascript would be a significant amount of work.

jonystorm14:04:35

Oh I see, I guess I’ll have to find another tool then, thanks

wilkerlucio14:04:19

@jonystorm in general you will have more work to use datascript then otherwise, also you will lose on performance (reading maps directly is usually faster than processing queries), as anything it's a trade-off, you gain by having a more dynamic query access, but check the costs, it may not worth it

jonystorm15:04:17

I understand that but I need to do contextual debugging and save it through datascript.. probably will have to use a different approach, maybe an event listener to save the transactions myself

tony.kay15:04:43

@jonystorm I would not recommend using DataScript as the UI database. However, you could certainly use it alongside.

tony.kay15:04:01

I've not had time, but I have been thinking about making the plumbing of Untangled more exposed and composable, which might enable integrations like that more easily without compromising the default simplicity.

tony.kay15:04:47

Typically, if ppl want to use DS I recommend having txes that feed into DS and your local app state, so that UI queries come from "views" of your data model. Where your data model is stored is technically an orthogonal concern.

tony.kay15:04:57

e.g: tx adds a person. Add it to DS, run DS query, turn that into view graph, swap that into atom...all as a single tx. Now your data model is in DS, and your views are in UI db. Still eliminates need for parser, etc.

jonystorm15:04:48

@tony.kay ok, that’s interesting.. We’ll give that option a try, thanks!