Fork me on GitHub

Could a response to a query from the server be sent already normalized or would there be anything lost then? Is there a reason for the normalisation to happen on the client? Maybe I just realized why, because we've only declared the idents on the client, we only know there how to normalize it? In my case I happen to know the idents on the server (it's always the uuid field), and it's less work to return the data in an normalized form. Is there any problems doing so?


@maxt this kinda breaks the separation of concerns, in the current suggested way the server never has to know about idents at all, normalization is an optimization for the client, the server shouldn't know about it. doing on the server you can also break things, for example, pre-merge augments data as its gets merged, on the client, if you normalize on the server you lose that. so In general I wouldn't recommend normalizing on the server


Additionally, the whole idea is the the client can flex in any arbitrary way and the server need not change. You don’t want to have to refactor your server every time you make a UI change (say you restructure the UI to a new shape…now your pre-normalized stuff doesn’t match).


The whole point is that a client can make an arbitrary tree-based query to the server that matches the UI shape, but that the data is normalized on the client so you can work with it easily. Pathom is how to make it easy.


There is never a need to make the tree if you’re doing pathom assembles that for you. I have a feeling your trying to write some big query in one endpoint and build the tree manually…that is definitely the wrong approach on the server @maxt , but I could see why doing it that way would make you ask that question 😉


New release of Electron Inspect: This is probably it for the time being. Most things are working well, you can set the websocket port, and the css has been cleaned up.


A Chrome extension update will be released soon to include the new db explorer

👍 28