data-dom-id collision with (fragment) caching
#437
Comments
|
@michaelbaudino Thanks for reporting this. We should get a fix out ASAP. If you have any other feedback, please let me know. A PR would definitely be appreciated. |
|
@michaelbaudino We probably don't actually need the auto-generated DOM ID for anything other than integration tests (what do we need this for?): Let's have a config setting:
@jbhatab @thewoolleyman @alexfedoseev @robwise Any comments? Feedback is welcome. We'll need a major version bump for this. In the very short term, we need a doc PR to address this. We should have a doc file for Fragment Caching tips. (any volunteers?: call it @michaelbaudino Please share your tips on how you set up your cache key with react_on_rails. I'd like to consider eventually making a helper for this. |
…d index. This ensures that all DOM nodes ids are unique when multiple instances of a component co-exist on the same page. It also allows fragment caching of generated HTML (since the unicity does not depend on other components on the page). Solves shakacode#437
|
@justin808 You mean, kinda like #438 ? 😄 |
|
Yes, for anybody reading this. See #438. Big thanks to @michaelbaudino for fixing this! |
…d index. This ensures that all DOM nodes ids are unique when multiple instances of a component co-exist on the same page. It also allows fragment caching of generated HTML (since the unicity does not depend on other components on the page). :warning: one must use the `id` parameter of `react_component` to force the generated DOM node id in order to have a predictable one (_e.g._ in tests). This commit also includes the CHANGELOG update and the version bump. Solves shakacode#437
|
I want to get this one merged. The only thing holding me back is getting consensus on doing a major version bump. I think it's prudent to do a major version bump so somebody doing updates will look at the CHANGELOG.md. @michaelbaudino Agree? |
|
Sure, great ! Thanks a lot ✨ |
We encountered a problem where
data-dom-idof components on the same page are not unique.This is particularly obvious when components are stored in cache fragments and can be ordered differently depending on parameters. For exemple, think about search results where each result is a cache fragment containing a component rendered using
react_component(the fragment will contain thedata-dom-idauto-incremented based on the rank this result had in the page when rendered the first time).For the record, if some people have the same problem, the workaround we found is to explicitely define
data-dom-idusing theidparameter of thereact_componentmethod as documented here.The point of this PR is that the default
data-dom-idshould actually not be auto-incremented based on the rank of the component in the page, but rather by an UUID or (even better, but not sure if possible) by a MD5/SHA hash of its content.PS: I saw a few existing issues related to fragment caching, but it was more about cache invalidation, not that kind of collision.
The text was updated successfully, but these errors were encountered: