@souenzzo have you looked at the mutations and network tab of the inspector?

could be that you’re getting duplicate data like Tony said (network tab), or duplication transactions invoked (transactions tab)

or non-duplicate transactions but poorly behaving ones

seems like it has to be of those three, and it would be good to figure out which one first

is the any way to provide :vendors and other options(https://github.com/noprompt/garden/wiki/Compiler) to garden.core/css when im using colocated css?

@mateusz.probachta https://github.com/fulcrologic/fulcro/blob/4dd64766032500eb25a3d535a76ab05a2b152447/src/main/fulcro_css/css.cljc#L66 doesn’t seem like it

I saw it but I had hope that I missed something. Any objection about possible pull request with this? I will need this so I prefer have this in fulcro than in my code:D. Is good idea to extend css related function by one extra arrity?

(defn css-something 
  ([component]) 
  ([subset-of-garden-options component]))

That’s a question for @tony.kay 🙂

yeah:D

@mateusz.probachta I’m working on a strategy to get this kind of stuff out of fulcro core. As it stands anything in the options map of defsc is hard to mess with…using protocols, so changes at that layer need new names or they are unacceptable breaking changes. As far as “helper” functions in the css namespace (e.g. for converting through garden), I don’t mind adding an extra arity for an “options” map if that makes sense. Also, why are we talking about the deprecated things in the old ns? Please don’t ask me to read a bunch of docs and source I wrote years ago to understand your request…

A clear pointer to a real function in current version with what you want to do will get a clear answer

Sure, my bad. I meant fulcro-css.css-injection

@mateusz.probachta sorry that was snippy…just get a lot of requests and been busy lately

If you’re asking if you can add an arity to a normal function in css-injection to pass extra args to garden, the answer is yes, as long as it is a non-breaking change for existing users.

the arg order should prefer the component…options are last by convention in Fulcro.

I keep trying to figure out what the wording is for this “implicit convention” we have for argument order…sort of like “you pass the things you have the least influence on first”…not sure that’s the right way to say it…but a db connection, or component, or something…typically “first”…

Ok, i do not want break this convention. And yes i want add it;).

another general rule is “multi-arity functions preserve the order of the lesser arities”…you don’t switch arg order as it goes up

so sure, send over a PR

Hi, quick question one of my guys is trying to implement an autosave feature, for a form component that has a generic save mutation. we need the save func to check the form state etc, prior to firing the mutation. of course the issue is that is that if we say call setInterval during the component’s mount, we’re closing over component’s this in the callback at the point that setTimeout is called, so when it actually executes, it’s not getting the current data. Any ideas on how we might circumvent this?