Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node re-use carries over DOM state like :focus #170

Open
wildlyinaccurate opened this issue May 9, 2020 · 3 comments
Open

Node re-use carries over DOM state like :focus #170

wildlyinaccurate opened this issue May 9, 2020 · 3 comments

Comments

@wildlyinaccurate
Copy link

When DOM nodes are re-used between renders, some of the state is carried over. I made a simple demonstration of this where the button retains its :focus state despite being written as .

Some of the DOM state (focus in particular) is important for accessibility. For people using assistive technology, it can be quite jarring to have the focus appear to move between elements like this.

@wildlyinaccurate
Copy link
Author

wildlyinaccurate commented May 9, 2020

For what it's worth, React has the same issue when re-using nodes within a component but not when using separate components. Does Elm have the equivalent of that second React example?

@pdamoc
Copy link

pdamoc commented May 10, 2020

This is one of the cases where it is recommended to use a Html.Keyed.node.
Here is your example fixed with this technique.

@wildlyinaccurate
Copy link
Author

I think we're having the same conversation on Reddit. I'm aware that keying the nodes will force a re-render and fix the problem in my specific and contrived example. I don't think it's reasonable to expect Elm developers to a) know that this issue exists and b) know how to use Html.Keyed properly (using it too much affects render performance, using it too little leaks state between unrelated nodes).

What I was hinting at in my previous comment is that other virtual DOM implementations have implicit keying (or enforce explicit keying in certain circumstances) in a way that makes this a non-issue. I think it's reasonable for Elm to attempt to do the same. One way might be for Elm to implicitly key child views based on their function name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants