Fork me on GitHub

I'm trying to merge in styles conditionally using component props in a garden css rule using fulcro-css, but it looks like they're not visible to :css given how the defsc macro expands. Does anyone know the idiomatic way to conditionally construct css rules based on props?


something like this:

:css [[ (merge {:background "grey"} (if my-prop1 {:background "red"} {:background "green"}))]]


@danvingo the css is generated statically from the classes, you can't use props for their definition


to have dynamic styles, use the :style property directly on your render


thanks, I was just coming to that realization


no problem 🙂


will take a dive into attempting to integrate


hmm, not sure using template strings is going to work from cljs


@danvingo why not use atoms? The rules are running logic, it just isn’t from props.


@tony.kay I don't follow, I just want styles to change based on values from props.


You can also set different classes on your components based on your props


For theming if in the css you add logic using values from an atom, the you can update the atom and regenerate the css and update it in the page (css/get-css component).


for different styles based on props, I just add another class. In js there is npm class-names, the equivalent for clojure(script) is something like


Localized dom supports the :classes key which accepts a vector of classes


Nice :) missed the :classes option


I have noticed that calls to trf from the action thunk of a defmutation do not correctly interpolate arguments in Fulcro 2.5.4. Does anybody else have this issue? For example: (trf "Hello {name}" :name "Fulcro") returns Hello {name} instead of Hello Fulcro inside a defmutation.


@fatihict I'm not sure, but I believe it should have something to do with the dynamic vars, I guess fulcro has to access something from the dynamic vars that are defined during the render, and those are not available at mutation time


have to check the sources, maybe there is a way to bypass and send some of this directly, I can't look now, but hope this can be a direction for you to check


^ I think that is the right direction. I did look in the source, but I am not sure how to fix this properly


Getting ready to dive into adding HTML5 routing — taking a look at fulcro-template : and Any other pointers / sample code available? I’m actually relatively new to bidi/pushy so have some ramp up to do.


@fatihict i18n isn’t meant to be used from outside of the UI


@danvingo so two possible options: What @fatihict is suggesting: define multiple classes, and use props to switch among them. My suggestion was to put things that vary in atoms (e.g. like a theme) and base your CSS on those. Then you have global theming. Either works.


I think what @danvingo whats is much simpler than a theme change, it's just about a style derived from a state, atom seems overkill IMO


so I recommend different classes for the each state, or inline style override


@tony.kay I have a notification component which displays a title and a description which I set with a transaction. I have wrapped the title and description in a trf. This used to work before Fulcro 2.5, how should I rewrite my code to support this case now?


@fatihict In older versions the locale was a global, but this limited you to one app per web page. It is now part of state, and to get it to work we dynamically bind things for tr/trf to use to figure out locale and translation. Any messages in state (e.g. set via a mutation) should always be in the “default” language. Then render them with tr/trf in the UI


why do you want to translate it in the mutation?


app state should not have the translation or message? it should be state. tr/trf work on fixed lists of pre-known strings, so there should never be a reason to “compute” them like this.


@tony.kay I put notifications in the app state in order to display them one by one by a notifications component rendered by Root. When an events occurs in my app such as the creation of a new company I call a mutation which adds a notification with a title (trf "The company '{company-name}' has been created" :company-name some-name) and some description.


@fatihict why not put company name in state, and the formatting in UI?


what happens when you switch locales? The mutations are not all going to re-run..the tr MUST run in UI, or it simply won’t work right


say you get three notifications, and the user switches locale in the middle…the “old” ones will be in the wrong locale


tr is a UI concern, never a state concern


the message novelty can be a state concern, but format it via calls in the UI..e.g. give them message types and novelty in state, but do the formatting in UI code


Ah oke, that makes sense. Thank you for the explanation!