Clojurians Log v2

So will a scaled up version of

[:div
  (for [k (get-thousands-of-keys)]
    ^{:key k} [some-complex-component (get-params k)])]

(into [:div]
  (map (fn [k]
         [some--complex-component (get-params k)]))
  (get-thousands-of-keys))

Probably the difference is quite small if the order and the set of items is same for each render. Difference is most obvious if React has to add some DOM elements between old elements or such.

Ah, right. So reordering would be more efficient as well, it makes sense.

FWIW this benchmark is useful comparison for keyed vs. non-keyed differences https://krausest.github.io/js-framework-benchmark/2021/table_chrome_89.0.4389.72.html

keyed is faster for certain ops and non-keyed for others

so depending on how your items change it might be better to use one or the other. it can be significant.

Hold old. How can you compare? Between keyed and non-keyed tables, React versions are different. And Reagent is not even present in the latter.

just compare react. the version difference doesn't matter much.

There is separate implementation for keyed / non-keyed version. Reagent only has keyed implementation for that benchmark.

nowadays the implementations are pretty good across the board so keyed is pretty much a no brainer in all situations

Then the results are very strange. Swapping two rows without keys is more than an order of magnitude faster than with keys.

Keys have another disadvantage - it's not always easy to come up with the right key given a set of complex props.

yes, because of the underlying dom operation it does

non-keyed it changes the text of 2 dom elements but doesn't move them. so the browser doesn't need to perform a layout/style recacluation

for keyed it moves the dom elements and it needs to recalc the whole list in the worst case

Then why keyed would be a no-brainer, given that you still have to put extra responsibility on yourself to select the right key generation algorithm?

well most of the time you have some natural keys anyways

the into thing is pretty much the worst thing you can do performance wise but it is the only option to go non-keyed

so that will almost certainly lose to a keyed impl

Suppose I have a collection of entities with IDs and a bunch of text values that I need to display. That ID is natural, yes, so it makes sense to set it as a key. But those text values can change without any change to the ID. Won't using ID as a key prevent the items from being re-rendered when one of the text values changes? I definitely remember falling into a version of such a trap before, where there was an obvious natural key that ended up preventing the components from being re-rendered when needed.

No

but if you look at inferno for example the difference in swap rows for keyed/non-keyed is much smaller

so it is much more an artifact of how react handles this not general

no the key only controls ordering, it does not affect other updates

Id controls the component lifecycle and is used for DOM reconcilation, if component properties change, it will be re-rendered, key doesn't matter.

Hmm, perhaps I'm much more confused than I thought. Thanks for the info, I'll experiment with it.

> Won't using ID as a key prevent the items from being re-rendered when one of the text values changes? it will still re-render, but the way it changes the DOM and the component lifecycle may be different. keys are especially useful if you're trying to manage input/focus/component state/etc. in a list - you don't want React to blow away your DOM and component state of of all your rows if some data changes and you swap two rows

Hi all. Im using a re-com input-text area to do the text area in this -> https://text-to-wardley.vercel.app/

On my local before I release the text area is nicely sized to take up the left 30% of the page. Once I release it it just doesnt respect the width property and remains narrow, and certainly doesnt resize. any pointers?

Is there any code that we could look at?

This is the function here -> https://github.com/mlakewood/text-to-wardley/blob/main/src/cljs/text_to_wardley/views.cljs#L30

Im wondering if for some reason its not re-rendering, so i've added a sub for the window width / height

^^ that didnt work

The container that has the real textarea seems to have the right width. Check the div with class rc-input-text.

Seems like it's just the textarea itself that doesn't fill its parent width-wise for some reason. Maybe there's some issue in CSS? Something being used in dev but not making it to the prod?

hmm. yeah css might be it. I diffed the html and it was the same...

Check out Bootstrap CSS. Re-com requires it.

On the re-com demo web page you can see that the text area input has additional styles applied to it that all come from Boostrap.

ahhh.

hmm.. I do have bootstrap pulled in.

but thats a good guess.

Hi all, I haven't worked with reagent in quite some time. I was wondering if anyone could help out with the following issue on the reagent cookbook. https://github.com/reagent-project/reagent-cookbook/issues/62 For context, we recently bumped the reagent version in all recipes, but that broke this recipe (and possibly others). Also, I am unsure what is considered best testing practices these days. So I was hoping to receive help updating this recipe or replacing it altogether. PRs welcomed 🤞

You mean this Bootstrap? :)

There are also two fonts that aren't loaded, at least on my end.

oh good pickup.

Never use http:// to include resources in your HTML, always use //. It will use the same protocol your page was loaded with.

good tup

*tip

BINGO! thanks! looks like its working now

@ps Will you please stop cross-posting questions unless someone specifically tells you you’re posting in the wrong channel and should post a question elsewhere.

@seancorfield what if the post pertains to two topics?

Post it in the single channel you think is most appropriate. If someone tells you it belongs in another channel only then post it elsewhere (and remove it from the original channel).

That way folks won’t waste time dealing with a question in a channel when it is being dealt with in another channel.