Fork me on GitHub
#fulcro
<
2018-03-26
>
bbss09:03:45

Is the :state in the reconciler of my app supposed to be not-normalized after a load? On the server I use db->query to query a normalized atom with the root query from the client. That seems to work and my components get their data. The problem arises when I am pushing something through websockets. I try to use integrate-ident like the websockets example. But I keep getting an error must target an app-state vector. Which makes sense, because the state object I am passing seems to be just the tree.

danielstockton17:03:37

Can anyone update me on shadow-cljs vs figwheel? Is it supposed to replace the functionality of figwheel? Why did fulcro change to shadow-cljs by default?

levitanong17:03:19

@danielstockton AFAIK primary reason is cleaner, more reliable NPM support.

tony.kay17:03:12

@danielstockton that is exactly it. Leveraging libraries in the js ecosystem is just easier and better with shadow, and since you’re building UIs that often want to use that ecosystem, it seems better to use it. It does the hot code reload and REPL, so figwheel isn’t needed.

tony.kay17:03:28

but figwheel is still an option on the template

tony.kay17:03:00

@bbss merge-component! is probably what you want. Normalization isn’t magic. You have to have component queries that match the incoming tree of data.

danielstockton17:03:26

Hmm, ok. Would you say this switch is happening in the wider community? Are there any secondary benefits? I actually don't care much for npm/js ecosystem integration - in fact, I almost consider it a feature that it's a bit clunky.

tony.kay21:03:03

@danielstockton I don’t know what the wider community is doing. If you write nothing but clj/cljs and use nothing from the js ecosystem, then either will work fine for you.

tony.kay21:03:59

there are secondary benefits: the caching behavior is better, for example, leading to better responsiveness. I’ve got consulting clients and it’s hard to tell them “we should write our own widget to do blah” when there are half a dozen decent ones in the React ecosystem already, that work as controlled components, and are well tested. Seems insane not to use some of them in a business context. I agree that some are of poor quality, and so that needs to be part of the equation, but I don’t find it ethical to ask a business to spend huge amounts of HR money on something that already exists.

👍 4
danielstockton06:03:36

Yep, I understand the reasons why it could be desirable. I just usually work in contexts where control over the UI is more important than lots of generic widgets, or on side projects where it's my own time. I also probably haven't met some of the pain points. I do use some js libs (not usually react components) and find cljsjs packages to be just fine.