Fork me on GitHub

@leblowl you only need to wrap a lazy list if you are dereffing a ratom inside


@U8ES68TGX Thanks for the response. The first point is good to know - I bet I have done that in my code. I found some other docs on it also, but I don't see it in the main docs yet: ... About the keys and lists. I think I understand the need for keys and how they help performance with lists. I guess I am curious if keys are specific to list data structures or if they are also helpful for plain-old children. For example: [:div [:div] [:div]] vs [:div (list [:div] [:div])]. When using Clojurescript and into we can dynamically generate the first div from a list. I see some libraries do this (accept a list and into the list into a div). Do you know if React will make use of keys anyways in the first example?


@leblowl it is mentioned briefly here (item 4), but admittedly this is kind of out of the way


in terms of your other question:


yes, there is a difference between [:div [:div] [:div]] vs [:div (list [:div] [:div])]. The latter version passes the sequence to react differently than the first version. React only attempts to do its key-based optimization if you pass using the later convention


there are lots of times when just using into is fine because you are not going to manipulate a sequence in a way that would allow the key optimization to do anything useful for you. e.g., if you are creating a drop-down menu from a map of keys, the elements in the dropdown are always going to be in the same order, so you really don’t need to invent keys


Good to know. Thanks for the reference to the docs too. I figured it was in there.


in terms of the performance impact, using a sequence with keys can potentially help performance if you have meaningful keys and do things like move/insert object in the sequence (and the sequence is long)


often a sequence will never be edited in that way so there’s no performance impact. i.e., the sequence is a menu or something that isn’t really dymanic


in that case, into is just easier


Is there a go-to solution for resetting/maintaining scroll position when using an HTML5 History API-based router?


I.e. the equivalent of — where navigating to a new “page” should scroll to the top, whereas pressing back should restore the previous position?


@orestis I have an idea: on navigate, save the scroll position in your app state and use CLJS/JS to modify the DOM on page load or use that state in a component.