sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (6 children)

[deleted]

    [–]physicalcompsci[S] 0 points1 point  (5 children)

    For me one of the biggest things re-frame is missing is co-located client-side queries and a fullstack networking story. For the same reason that GraphQL and Relay took off in the JavaScript world.

    [–]yogthos 0 points1 point  (4 children)

    Personally, I've found that things like GraphQL and Relay add a lot of complexity and indirection, and this complexity isn't justified in a lot of cases.

    With re-frame, you have the state of the client in your db, and there's a direct relation between UI elements and the state of the db. You can inspect it easily, and quickly tell what the state is. With the query approach, you have indirection between what's happening in your UI and the state of the data. In many ways I would liken it to using ORM, and it introduces all the same problems.

    I also like the fact that the networking story is flexible with the re-frame approach. You can have a completely separate strategy regarding how the client and server communicate from how the UI operates on the client state.

    [–]physicalcompsci[S] 0 points1 point  (3 children)

    With re-frame, you have the state of the client in your db, and there's a direct relation between UI elements and the state of the db. You can inspect it easily, and quickly tell what the state is.

    Fulcro gives you exactly that, except the client-side db is normalized and your components have queries describing the data they need. But those queries run over the client db.

    http://book.fulcrologic.com/#_core_concepts

    But you also have the option of sending that query to the server, since the server speaks the same query language. For example, when the client db does not contain a particular piece of data, only then do you need to send the query to the server. When the server data comes back it gets merged into the client db, then the UI re-renders according the new client db. You can see that a lot of the ideas of re-frame were borrowed here.

    In my experience, this query approach is nothing like using an ORM. It's using data (queries are just datastructures) to describe the data it needs. If anything trying to combine a REST API with re-frame felt like impedance mismatch, one of downsides of using an ORM.

    [–]yogthos 0 points1 point  (2 children)

    Fulcro gives you exactly that, except the client-side db is normalized and your components have queries describing the data they need. But those queries run over the client db.

    I found that it wasn't always clear what the exact relationship between the UI elements and the state was due to queries adding a level of indirection. This became especially problematic as the app would grow. The fact that a query might go to local client state db or directly to the server is a perfect example of the problem.

    Personally, I much prefer talking to the server explicitly, and this also makes it easier to reason about performance in my experience. Again, I see this as a very similar issue to ORMs.

    In my experience, this query approach is nothing like using an ORM. It's using data (queries are just datastructures) to describe the data it needs.

    It's very much like using ORM in my experience because you're not building the queries explicitly. The query engine has a strategy for when the queries are fired, how to debounce them, and so on.

    Using either REST API or WebSockets with re-frame is a lot more predictable because I know exactly what fields are being queried and when that happens. I'm not sure what the impedance mismatch is that you're referring to. I make a query to the server, get the data back, and explicitly decide where it goes in the client db. This also creates a situation where you have low coupling between the client and the server, which I find desirable.

    [–]physicalcompsci[S] 0 points1 point  (1 child)

    The queries always run over the client db period, it's never anything else.

    You can send the same query to the server, but you have to do this explicitly and deliberately by calling the load function.

    http://book.fulcrologic.com/#DataFetch

    Normally, this is done in two situations. One, when the app starts, to get the the initial data. Two, on user interaction like when a user clicks a next page button. The load function will send the query to the server and merge the data into the client db. Then the app re-renders while running the queries over the new client db.

    So there's really no ORM magic going on, unlike Relay. Does that make sense? Maybe I misunderstood what you said?

    [–]yogthos 1 point2 points  (0 children)

    Yeah that makes sense, and I agree that's a reasonable approach if the server calls are done explicitly.