No luck with trying again, seems to be just an error without much explanation.

I wish to announce a Fulcro tool that will let you know as soon as your client state becomes not normalized: https://github.com/chrismurrph/default-db-format

@tony.kay and @wilkerlucio Thank you for your replies.😊 First: yes your snippet is just what i mean,but not what I really mean. Yes, I was not aware of that co-css is initialized early than props.But I am not wanting dynamic updates during rendering (I can do that by togging :ui/some-state to add or remove delta-stye-className).I am more talking about to use other author’s defsc-component-with-coCSS by providing my initial-style-param. Second: yes I was not aware of this overwriting problem that when customizing the co-className more than once.But is the className overwriting conflict really be a problem? After all we usually just use one kind of style-param-initialized ui-component. What about this : (def ui-orangered-componentA (prim/factory CoCSS-componentA {:keyfn :db/id :style-initial-params {:background-color (rgb 255 69 0)}})), and in this project there is no other-kinds-of-styled componentA, so there is no conflicting problem. Because the className is pre-fixed by the co-component’s name,it is already portable/reusable,I just wondering if it can be pushed further with style-initializing-params. I just read this site “http://MaintainableCss.com” and the author’s main point is “domain-semantic-className is maintainable than style-fragment-classNames-composing”.Fulcro-css’s co-locating is providing a kind of maintainable,it’s className extracting is implying that it is semantic by user not composing by fragment-classNames. Can it be pushed further by provding customer-initial-style-params? But after further thinking,maybe “domain-semantic-graininess” means you can not use other author’s style-lib.The lib-author do not know the lib-user’s domain so that he can only provide generic style-snippet-classNames for the wide range of usability. Did not think this problem through completely.Just pouring my thoughts out for inspiring new ideas. Maybe it’s a fake demand. Maybe copy and edit is more economical.And sorry about my poor english.😊

@cjmurphy I will expand that error. It means you need to npm install intl-messageformat

@eric.shao It seems to me that ultimately what you’re looking for with co-lo css is safety: no accidental conflicts. If you follow the namespacing conventions of java-land (which we unfortunately have a habit of not doing in Clojure), then every component would be guaranteed to have a globally unique name, eliminating css naming conflicts. As far as “tuning” css to a user’s desires: that is either properties passed in as parameters and placed in style elements ( not affecting the global css for a local concern ) or it is a global concern that can be solved with some global bit of data.

so is everyone switching to shadow-cljs 😄

It’s pretty nice…esp where you’d like to use js stuff from the large ecosystem.

I’m strongly considering porting all of the Fulcro libraries to it, and making it the default in the lein template.

Fulcro 2.2.0 is up on clojars. Removed the timbre dependency (though you may still get that from other libs), and added new websockets support. Developer’s guide is updated as well. The github websockets demo was also updated/ported to the new support.

I'm liking shadow-cljs too, once you get used the settings are easier to handle, and of course, the js support