4 ms·

> Naively re-rendering a whole component using .innerHTML should be avoided as this may hurt performance and will likely break important functionality such as i

> Naively re-rendering a whole component using .innerHTML should be avoided as this may hurt performance and will likely break important functionality such as input state, focus, text selection etc. which browsers have already been optimizing for decades. I think this statement deserves some serious scrutiny. In many cases the performance hit may not be relevant or noticeable. I know this because I've been very productively using the following approach to build dynamic webapps for my personal use: 1. Compose HTML strings using Javascript, especially with string interpolation 2. Slap the resulting strings into div/span elements with innerHTML= statements. This approach results in extremely clean and simple code - much cleaner than the OP's code in my view. I have never noticed any kind of performance issues, the updates are always instantaneous. I don't know what the author means by breaking functionality like text selection and focus, but it's never been relevant for me. For an example of the coding style, see the reDispActiveTable in this code, which draws a table of TODO list items with some operations like edit/delete/mark complete. https://github.com/comperical/WebWidgets/blob/main/gallery/minitask/widget.jsp#L296 https://github.com/comperical/WebWidgets/blob/main/gallery/m...

eliseumds 6y ago
That's what OP means: https://codesandbox.io/s/elastic-rubin-hxpcw?file=/src/index.js https://codesandbox.io/s/elastic-rubin-hxpcw?file=/src/index... And that's why reconciliation algorithms became so popular. You can't be serious when you say that losing input focus and text selection have never been relevant to you. Basically, dealing with the internal state of components down the tree becomes a nightmare.
- ericmcer 6y ago
  it is possible to track and set cursor location after updating innerHTML... it is definitely no longer simple and clean though haha. https://codesandbox.io/s/zealous-vaughan-qd3gg?file=/src/index.js https://codesandbox.io/s/zealous-vaughan-qd3gg?file=/src/ind...
  - eliseumds 6y ago
    Your answered yourself there. It's not only about input focus, it could be anything really, like loading state, form values, progress indicator, etc. People will be basically building yet another framework at the end. React is not the only solution, there are plenty of lighter alternatives. OP's solution is just very type-unsafe.
  - SahAssar 6y ago
    IIRC it will also lead to weird behavior for people using screenreaders, they usually restart saying whatever they where reading when the element was replaced even if the contents are the same.
morrvs 6y ago
You bring up an interesting point. I intentionally used "may" in that statement as using .innerHTML can be both effective and performant enough (and a lot simpler). A couple possible problems off the top of my head: 1. CSS transitions won't work if you re-render a complete chunk of HTML instead of toggling a class. 2. <a>, <button>, <input>, etc. may lose focus or even data on re-render (e.g. while filling out a form). 3. Text selection may be reset on re-render. 4. If you don't use event delegation, event listeners may need to be reattached. I agree that for raw display .innerHTML may be sufficient, but it's surely not in general. That would make React almost irrelevant, by the way, which would be a huge surprise.
nymanjon 6y ago
If your user data isn't sanitized you could run into your site being hacked.

eliseumds 6y ago

That's what OP means: https://codesandbox.io/s/elastic-rubin-hxpcw?file=/src/index.js https://codesandbox.io/s/elastic-rubin-hxpcw?file=/src/index... And that's why reconciliation algorithms became so popular. You can't be serious when you say that losing input focus and text selection have never been relevant to you. Basically, dealing with the internal state of components down the tree becomes a nightmare.

ericmcer 6y ago
it is possible to track and set cursor location after updating innerHTML... it is definitely no longer simple and clean though haha. https://codesandbox.io/s/zealous-vaughan-qd3gg?file=/src/index.js https://codesandbox.io/s/zealous-vaughan-qd3gg?file=/src/ind...
- eliseumds 6y ago
  Your answered yourself there. It's not only about input focus, it could be anything really, like loading state, form values, progress indicator, etc. People will be basically building yet another framework at the end. React is not the only solution, there are plenty of lighter alternatives. OP's solution is just very type-unsafe.
- SahAssar 6y ago
  IIRC it will also lead to weird behavior for people using screenreaders, they usually restart saying whatever they where reading when the element was replaced even if the contents are the same.

morrvs 6y ago

You bring up an interesting point. I intentionally used "may" in that statement as using .innerHTML can be both effective and performant enough (and a lot simpler). A couple possible problems off the top of my head: 1. CSS transitions won't work if you re-render a complete chunk of HTML instead of toggling a class. 2. <a>, <button>, <input>, etc. may lose focus or even data on re-render (e.g. while filling out a form). 3. Text selection may be reset on re-render. 4. If you don't use event delegation, event listeners may need to be reattached. I agree that for raw display .innerHTML may be sufficient, but it's surely not in general. That would make React almost irrelevant, by the way, which would be a huge surprise.

nymanjon 6y ago

If your user data isn't sanitized you could run into your site being hacked.