Closed ghost closed 9 years ago
We actually could easily remove the classes and ID's, they are there for convenience and extensibility. Do you have any reason you'd rather no have the ID's and classes? They aren't necessary for the library internally, and technically externally either. But given it will be consumed by a wide variety of apps, would be nice.
I'd be open to removing the ID's, but again, debugging purposes they are nice. Perhaps in production I could strip them out.
Given that's not a problem, what would shadow DOM give us?
for debugging we use instrumentation, inspired by this talk https://www.youtube.com/watch?v=OZGgVxFxSIs
I tried this as well, but it's not compatible with Webpack last I checked. I opened a ticket. Again, I can remove the ID's do you know if that affects performance?
Our consumers can use shadow DOM if they want encapsulation, but from the ReactConf talk on shadow DOM I think it's actually impossible for us to use it. It would short circuit React whenever someone used a component of ours, and nearly all of them should be nested.
hi,
instead of spamming the dom with ids and classes like id=ui-27self and id=ui-27inner i think a better way is to use shadow-dom. each component regardless how often it is spawned in same app has its own namespace when put inside shadow dom.
with react-shadow a react mixin already exists https://github.com/Wildhoney/ReactShadow what do you think? does it make sense?