reagent

A minimalistic ClojureScript interface to React.js http://reagent-project.github.io/
p-himik 2021-03-23T10:09:53.012700Z

So will a scaled up version of

[:div
  (for [k (get-thousands-of-keys)]
    ^{:key k} [some-complex-component (get-params k)])]
be more efficient in terms of re-rendering a single item than
(into [:div]
  (map (fn [k]
         [some--complex-component (get-params k)]))
  (get-thousands-of-keys))
?

juhoteperi 2021-03-23T10:12:24.012900Z

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.

p-himik 2021-03-23T10:13:27.013100Z

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

thheller 2021-03-23T10:14:53.013300Z

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

thheller 2021-03-23T10:15:06.013500Z

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

thheller 2021-03-23T10:16:44.013700Z

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

p-himik 2021-03-23T10:17:47.013900Z

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.

thheller 2021-03-23T10:18:39.014100Z

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

juhoteperi 2021-03-23T10:18:46.014300Z

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

thheller 2021-03-23T10:20:58.014600Z

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

p-himik 2021-03-23T10:21:29.014800Z

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

p-himik 2021-03-23T10:21:48.015Z

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

thheller 2021-03-23T10:21:53.015200Z

yes, because of the underlying dom operation it does

thheller 2021-03-23T10:22:48.015400Z

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

thheller 2021-03-23T10:23:07.015600Z

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

p-himik 2021-03-23T10:23:43.015800Z

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?

thheller 2021-03-23T10:24:49.016Z

well most of the time you have some natural keys anyways

thheller 2021-03-23T10:25:12.016200Z

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

thheller 2021-03-23T10:25:44.016400Z

so that will almost certainly lose to a keyed impl

p-himik 2021-03-23T10:27:25.016600Z

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.

juhoteperi 2021-03-23T10:28:21.016800Z

No

thheller 2021-03-23T10:28:23.017Z

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

thheller 2021-03-23T10:28:37.017200Z

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

thheller 2021-03-23T10:29:02.017400Z

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

juhoteperi 2021-03-23T10:29:02.017600Z

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

p-himik 2021-03-23T10:36:48.018Z

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

lilactown 2021-03-23T14:53:04.018500Z

> 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

1👍
2021-03-23T22:08:01.019500Z

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

2021-03-23T22:09:12.020800Z

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?

p-himik 2021-03-23T22:12:22.020900Z

Is there any code that we could look at?

2021-03-23T22:18:34.021400Z

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

2021-03-23T22:19:23.021700Z

^^ that didnt work

p-himik 2021-03-23T22:19:27.022Z

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

p-himik 2021-03-23T22:20:04.023200Z

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?

2021-03-23T22:21:31.025700Z

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

p-himik 2021-03-23T22:21:55.026300Z

Check out Bootstrap CSS. Re-com requires it.

p-himik 2021-03-23T22:22:26.027300Z

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.

2021-03-23T22:22:44.028100Z

ahhh.

2021-03-23T22:24:00.029900Z

hmm.. I do have bootstrap pulled in.

2021-03-23T22:24:20.030500Z

but thats a good guess.

gadfly361 2021-03-23T22:24:44.030900Z

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 🤞

p-himik 2021-03-23T22:25:37.031100Z

You mean this Bootstrap? :)

p-himik 2021-03-23T22:25:56.031500Z

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

2021-03-23T22:26:25.031700Z

oh good pickup.

p-himik 2021-03-23T22:26:28.031900Z

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

2021-03-23T22:26:54.032100Z

good tup

2021-03-23T22:26:57.032300Z

*tip

2021-03-23T22:36:50.032500Z

BINGO! thanks! looks like its working now

1👍
seancorfield 2021-03-23T23:30:34.033600Z

@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.

zendevil 2021-03-23T23:32:14.033700Z

@seancorfield what if the post pertains to two topics?

seancorfield 2021-03-23T23:33:11.033900Z

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).

seancorfield 2021-03-23T23:33:35.034100Z

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