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:

[:div.fade-in-1s
  [:h "Step description"]
  [:p "Step contents"]
  ...]

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

Not yet. I haven't ever set something up

Perhaps I should setup a Github sponsors ability

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?

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

I was looking for https://github.com/reagent-project/reagent/blob/master/doc/CreatingReagentComponents.md#form-2--a-function-returning-a-function, which is under the reagent documentation.

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 https://github.com/day8/re-frame/blob/master/examples/todomvc/src/todomvc/views.cljs#L7

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

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

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?

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.

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.

awesome!

https://github.com/Day8/re-frame/issues/218 for history

form-2 is still very relevant when creating local states

not everything belongs in the app db 😄

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

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

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

I'm very influenced by this article: https://medium.com/@mweststrate/ui-as-an-afterthought-26e5d2bb24d6

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

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

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