@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

@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 https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html

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.

https://stackoverflow.com/questions/28922275/in-reactjs-why-does-setstate-behave-differently-when-called-synchronously/28922465#28922465 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.

@tony.kay thanks!