Fork me on GitHub
#untangled
<
2017-03-11
>
tony.kay01:03:56

@jasonjckn The client reads are whatever you send. But they always involve UI queries

tony.kay01:03:29

for normalization and data-driven concerns. It really isn't different from Om Next there. You use process-roots in Om Next to decouple to two instead

tony.kay01:03:57

I'm encoding the video now...will be up shortly

tony.kay01:03:10

hopefully it will clarify some things...white board, so please forgive my hadnwriting (and spelling evidently)

tony.kay01:03:02

The hardest part is what to call it and where to put it... 😕

tony.kay01:03:10

And @jasonjckn, the work is not pushed on the server by Om Next, it's pushed onto your parser emitter logic on the client, and into your networking, and merge logic for the responses. The server just responds for what is asked.

tony.kay02:03:36

So Untangled and Om Next both do exactly the same things when you look at the network traffic: use UI-based queries to ask for just what you want. In Om Next the parser is the function that takes app state -> UI tree. In Untangled, it is raw db->tree...so you pre-write the "computed views" of the server-loaded data into the app state graph. The video should clear it all up.

urbank08:03:13

@tony.kay Wow, that's a ~1h video! The support on this channel is amazing

tony.kay17:03:11

Thanks, but more importantly, did it help? 🙂

fz20:03:53

@tony.kay thank you so much. That video was the missing link that makes all the other resources make sense

tobias20:03:05

@tony.kay really useful video, makes the ideas and structure around loading much clearer, many thanks!

urbank20:03:42

@tony.kay Helped a lot! Really tied everything together for me 🙂