Fork me on GitHub

I am trying to do a fade-in animation with re-frame. I already have a fade-in-1s css class that works. The problem is that I have a form like this:

  [:h "Step description"]
  [:p "Step contents"]
This is part of a panel that will show several "steps", and I want the fade-in animation to play at every step transition. However, I can only see my the fade-in animation when the first step is displayed. When I transition between steps, only the inner [:h] and [:p] are redrawn, but not the whole div (I assume this is re-frame being smart and diffing the HTML). How can I force the redraw of the whole div, so the fade-in animation is triggered?


Hi @U70027S0N, may be you can set a new key at each refresh

^{:key new-refresh-key-here}[:div.fade-in-1s ...


that works, thanks! 👍

👍 3

Also remember that you can use libraries like Framer Motion here is an example of use

👍 3

There’s a really nice tutorial on framer-motion (for React) at framer-motion is pretty powerful but seems to require to use it at the bottom of the component hierarchy (i.e. motion implementation of html tags like motion.div, motion.button etc) I did find that at least for simple things so far, can wrap a reagent component into a motion.div and the animate of the motion.div animates the reagent component.


is there a preferred way to donate to re-frame? or perhaps just to an individual?

👍 6

Not yet. I haven't ever set something up


Perhaps I should setup a Github sponsors ability

👍 27

i sent you a pm this morning asking about channels to donate to you individually. seems like you have notifications off though. just wanting to see if you had any way to get you some money from our development team


I feel like I must be blind. I'm looking for the explanations of form-1 and form-2 components in the new re-frame docs and can't find it anywhere. are form-2 components not recommended anymore?

Pavel Klavík18:07:21

you can use subscriptions directly in form-1 components, I normally just deref directly @(rf/subscribe [...]) within let.


I'm going through the re-frame todo mvc example, and was looking for the docs on form-2 components to under stand the todo-input


are form-2 components idiomatic in re-frame? is there a better alternative?

Pavel Klavík18:07:52

they use form-2 components there because they want to use ratoms directly for inputs, so the state is not changed while typing the text into it

Pavel Klavík19:07:04

I haven't ever used anything like that (we are dispatching all changes), so not sure about idiomatic way in Re-frame


I'm pretty new to re-frame and I like the idea of sticking to form-1 components. Are form 2&3 components common for re-frame projects?

Pavel Klavík19:07:28

I think the change in subscriptions made form-2 unnecessary in most cases. In our code, we have almost all form-1 components, and a few form-3 components where we need to use React events like component-did-mount or component-did-update. If you are starting with Re-frame, just use form-1 for everything.

metal 6
💯 3
Pavel Klavík19:07:38

Beforehand, subscriptions has to be used in form-2 components because rf/subscribe couldn't be used for every rerendering which would cause memory leaks. But it was changed that it is cached now.


form-2 is still very relevant when creating local states


not everything belongs in the app db 😄

👍 6
Pavel Klavík19:07:31

what is something you would put into local state? like values of an input, as it changes?


collapsed/expanded state is something we have had there


my rule of thumb is: if I deleted the UI, would this state still be relevant? if so, app-db. if not, local state

👍 3
Pavel Klavík19:07:07

don't you get then into problems when something is local at first, but then you need it somewhere else? I found that impact of user interactions often influences very different places in the state of the app.


sometimes but not all the time


you can either lift it up to a parent and pass it as props (an easy, purely mechanical change with the ratom API) or - maybe it's relevant outside of the UI

David Pham19:07:00

My experience is form 2 was required whenever I wanted animation with JS comps. (Material UI).


yes. UI state needs to have very low contention. you want the minimal amount of mutations & subscribers in order to remain fast


app-db is just a free for all. as your app grows, every top-level subscription has to be run on every change. it's terrible for UI state


but, there are benefits to having a single source of truth for your application domain

Pavel Klavík19:07:39

hmm, speed is a benefit, I like having all of the state within one atom which makes the app little bit more clear (we have now about 25k lines). Not sure how this goes when it grows.


for us, our app is about twice as big and the app-db is an unmanageable mess


you can't print it w/o performance problems lol


the dev experience and tooling problem you're talking about is legit but there are ways to solve it that actually don't depend on keeping everything in one atom


you could keep things in multiple atoms and have lil bit of code that allows you to explore them all at once

Pavel Klavík19:07:21

hmm, how about using inspect in shadow-cljs instead of printing?

Pavel Klavík19:07:51

makes sense, currently it doesn't feel to me like a mess yet and if it becomes a mess later I will have to rethink the approach