Is the performance gain for creating subs once in form-2 components worth the extra code? It works fine with simple subs, but when I need to sub to an id and then pass that id into other subs it all goes to shit. Perhaps the pattern of subbing to an id and passing into another sub is a bad idea. Perhaps its fine to re-create the sub on re-render and there isn't much of a performance hit. perhaps there is another way to achieve this without recreating the sub on re-render. Anyone have any ideas?

I usually use the id pass through pattern as I'm iterating over a list of ids and then passing each one into the subs

I'm having trouble getting live reloading to work properly with re-frame and Shadow CLJS. It's reloading the code, but not refreshing the component that got changed. What am I missing in my configuration?

send code of the component

Could be a form 2 not correctly setup

It's any component I have

is it a form-1 or form-2?

1

And a React Fragment

Are you using the actual React fragment component?

I'm using [:<>]

ah okay that's fine

But not in a fn

How are you changing your component? updating a value in app-db? then subscribing?

It's a pure ui element

No, just updating the p component

Does it have to go through app-db for that to work properly?

and hard reload works?

If I refresh the page the component is correct

do you have :after-load set up in :devtools in shadow-cljs.edn?

Not sure what you mean so no

I'm using lein btw

And Cursive

after-load is called on refresh. The reruns mount-root which calls rerender in reagent

oh nice. Thanks

I knew it was something trivial

Yea it's happened to me heaps

does that work for you now?

Actually no

Still have to refresh the page

is your rerender function for reagent called mount-root?

it actually doesn't need to be. As long as the symbol matches up

It is

I went with the lein template

What does your mount-root code look like?

Exact same

and what does your shadow-cljs.edn look like?

That's in project.clj

Well I feel dumb

It did need to be in shadow-cljs.edn

ah okay. Makes sense I was confused about that too.

I thought that since when you set :lein true it would use the build config in project.clj, but I guess it completely ignores that

So I guess I'm not sure what it does read from project.clj

:lein true makes it use the deps from lein only afaik

Not much actually

So should I just nuke the :cljsbuild section?

yep

For example that's what my project.clj looks like with shadow-cljs

I'm still using profiles

So dev deps are separate

oh yea that should be all fine

Lots of updates to those versions btw

And thanks for inadvertently suggesting an http lib

I'll need that to set up Stripe

I use that because I put my http layer behind protocols

You might actually prefer this https://github.com/Day8/re-frame-http-fx

Oh nice

Sure

Thanks

I don't use it because I want to decouple my http layer from re-frame but not everyone does it that way

Decouple for what specific purpose?

Btw I went with bidi+pushy instead of secretary

Mainly to keep the concerns of dealing with a http api away from my business logic in the web app.

What does the rest of your shadow-cljs.edn look like?

Oh, I'm just generating the token on the web app and then sending the token to my backend server as per the Stripe docs

So I just need to POST

So no production build?

shadow-cljs release app

That does a production build.

Ah, well that's a little simpler

So it automatically sets the options

Double edged sword though

which options?

Like changing :optimizations for a min or test build

Which I haven't used yet

What's that from?

Docs https://shadow-cljs.github.io/docs/UsersGuide.html#_release_specific_vs_development_configuration

I think by default release does :advanced compilation.

I used to have different build so I can pass in different keys for staging, prod & development releases. However I use actual environment variables at compile time for that now

And I bring them in with a macro

Hmm ok. So you'd have to enable infer-externs for advanced to work

Afaik shadow doesn't need externs at all

I could be wrong though I'm not too sure

I never have to deal with externs. I use https://github.com/binaryage/cljs-oops to interop with js

Btw do you know how to get rid of the "cljs.core/-, all arguments must be numbers, got [#{nil clj-nil} number] instead" warning from zprint/focus.cljc?

Nah I don't get warning

https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs

I'm not sure what's bringing that in

Ah okay. in oops my syntax is pretty much (oops/ocall x "baz"). And because you're using strings not symbols you don't need to worry about anything getting munged in advanced comp. Dealing with externs was a pain in the ass. This was before I starting using shadow-cljs though

Yeah, luckily I haven't messed with ClojureScript enough up til now so I haven't experienced those woes

@caleb.macdonaldblack Checking: when you say " it all goes to shit" ... you are talking about performance, right? Checking: for case 1, Style A and Style B should have the same performance, true? The cost of recreating an existing subscription should be tiny. Checking: should line 27 be @foo-id or just foo-id? I assume the later.

Sorry "it all goes to shit", I'm referring to that the code becomes really hard to write. I have to create children components to get it to work without creating subs in the render code

For your third comment, the later is correct

and "for case 1, Style A and Style B should have the same performance, true?" This is pretty much my question. Is it efficient to create subs in the render section of a component. I'm hoping so, because components become a lot easier to write. I wasn't sure if there was much overhead in re-creating the sub every time.

Is there a large number of these components?

Not really

In that case Style A and Style B are essentially the same

Do you think the same can be said for anonymous functions? Such as #(rf/dispatch [:foo])?

re-created on each render?

There is very little cost to "recreating" an already existing subscription

They are cached. So its the cost of a map lookup

Yes, DOM event handlers can sometimes cause unnecessary rendering

Because this evaluates to false (= #(rf/dispatch [:foo]) #(rf/dispatch [:foo]))

Ie. the DOM event function we create this time will not test equal to the one we created last time

So would it be best to move them out of the rendering and just use references/symbols?

Yes, some mention of this here: https://github.com/Day8/re-frame/blob/master/docs/Performance-Problems.md#4-callback-functions

Awesome thank you. Also lastly do you think looping over ids and passing them into subs/events is a good idea in general? It seems to work okay when the db is the only input signal. However for subs that have multiple input signals that need the id it becomes a pain.

That document has some advice

Sorry to clarify that's multiple levels/depth of input signals

And consider using re-frame-10x to get insight into what is happening and why

Okay thanks. That doc and re-frame-10x is very helpful. I'll definitely look into that right away. :thumbsup:

👍

Thanks for making 10x. It's super helpful!

Thanks. I wish we had more time to do more on it.

There's still a lot of untapped potential

Any idea what this warning is about? "Warning: unmountComponentAtNode(): The node you're attempting to unmount was rendered by another copy of React."

I might just be seeing it when it live reloads incomplete code

Interesting! I've never seen that when working with JS React, but it could be something about the hot reloading

does anybody know how to give a CSS style property multiple values, with re-frame's hiccup?

image-rendering: -moz-crisp-edges;
image-rendering: -webkit-crisp-edges;
image-rendering: pixelated;
image-rendering: crisp-edges;

@regen you won’t be able to do this with reagent (and by extension, re-frame) directly

you’ll need to use CSS