fulcro

Book: http://book.fulcrologic.com, Community Resources: https://fulcro-community.github.io/, RAD book at http://book.fulcrologic.com/RAD.html
tony.kay 2021-03-28T04:01:16.197100Z

Thanks for the reminder. Done.

1❤️
tony.kay 2021-03-28T04:03:34.197300Z

The design is an intentional one: The database and EQL are intentionally naive, and just walk a literal graph. This is a performance and clarity decision. If you want to choose a local database with more capabilities that is more feature rich, you are certainly capable of doing that. Everything from rendering to transaction processing is pluggable. You’re living in a world of distributed systems. Cache invalidation is just a thing you have to cope with, so choose your poison 🙂

Aleksander Rendtslev 2021-03-28T11:55:19.199200Z

What would be your suggestion here? An additional remote? or plugging in a new rendering and transaction handler? It definitely makes sense! I'm just trying to understand the downsides/upsides of each approach

tony.kay 2021-03-28T19:02:52.199500Z

My suggestion is to not complicate your code. use pathom to generate edges where you need them, query that from the server, and don’t worry about it on the front-end at all if you can.

tony.kay 2021-03-28T19:03:09.199700Z

don’t make some complex thing in the distributed side of the app

tony.kay 2021-03-28T19:03:50.199900Z

query for things from the server when you need them, let pathom connect the dots, use them as naively as possible on the front end

tony.kay 2021-03-28T19:04:30.200100Z

anything else is a dramatic increase in complexity. I guess if you find a real need to do that, you can of course…YMMV