Fork me on GitHub

@hjrnunes Although going with shadow-cljs might still be the better option, I have run into this particular issue and found out a workaround that solved it for me: the semantic-ui-wrapper has two factories, sui-factory and sui-input-factory. In some cases (I have not exactly deduced which), the ui-dropdown, which is effectively (sui-input-factory “Dropdown”) does not render it’s children, however if you use (sui-factory “Dropdown”) it will render the children seemingly fine. (I’m saying seemingly, because I assume it was changed to use sui-input-factory for some reason, but I’ve not seen any trouble with it in these cases).


@liesbeth Thanks! I'll give it a whirl!


@levitanong If you use co-located CSS, then any components you don’t use should be DCEd


I mean, if you use a component, but for some reason don’t call upsert-css, (say, because you already precompiled it into a css file for production) would the component’s css still be included?


The CSS won’t be emitted to the page, but the source of the CSS is compiled into the resulting js file, yes.


well, the garden data structure is what would be there, technically


In terms of transfer: the garden data structures are going to be smaller than a precompiled CSS file. Why not do the upsert in production???


We can’t assume our market will have good phones, and if the JS compiles css, then that’s one more thing their mobile browsers have to compute before the app becomes useful. 😞


Have you measured how long it takes on a median phone? I would bet that the network data size is comparable (meaning transfer times are similar), and that the computation itself is rather small. Seems like a good measurement and quantification of things should precede any optimization that complicates your deployment.


I mean: you can assume they’re better than iPhone 1…which runs nothing anymore (I’ve still got a working one, and I can attest it is useless).


@tony.kay I didn't verify this yet but I'm fairly certain that no defsc component will ever be DCEd due to the fp/factory call


@thheller hm, so the js output would be something like a var assignment with a side effect, and since Closure cannot tell if that side-effect was necessary it can eliminate the unused var, but not the side effect, and thus not the component…that is probably right


So I guess it would be better to say “if you don’t require it, then it shouldn’t end up in the code to begin with”? But of course that is at the file level, not component or CSS level.


well the require part is true for shadow-cljs but not always for other CLJS tools


but yeah closure can't figure out that the side-effect isn't required. therefore some.ns.ui_component = fulcro.client.primitives.factory(...) just removes the some.ns.ui_component = bit but not the actual factory call and thus keeping the component alive


just another reason to use shadow 🙂


(I didn't actually verify that the DCE doesn't happen though so it may actually happen. it is always a toss up what closure will and will not understand properly ;)


@liesbeth Yeah…simple fix. I went ahead and did the fix and tested it, and push 2.0.2 to clojars.


I forgot the input wrapper adds a layer so that async events from state updates don’t cause test inputs to behave erratically. It was not passing children


@hjrnunes that does mean that the wrappers supply something worth having…though it is trivial to add it to other inputs yourself. React assumes “controlled” inputs will be controlled from component-local state…controlling them from an external library like Fulcro (or Redux for that matter) causes an issue with textual inputs…Fulcro’s DOM inputs wrap the underlying React inputs to prevent problems, as do these semantic UI wrappers.

tony.kay17:09:38 is a great thing to read, though it is slightly different in Fulcro the underlying problem is identical: your keypress causes an event, which (if you use transact!) causes a state atom update and a request to re-render. The browser has updated the (mutable DOM) input value, but React still thinks it should be whatever you passed in :value. If React re-renders the input with that old value (forcing the value back in time), and then the Fulcro state update causes render with the new props (with the new value) you’ll get a flicker and cursor jump.