The Decorator problem: let’s say a “theme” makes structural changes that are patterned. For instance, a “theme” that changes time locale to some user specified locale. With jQuery, this can be done by identifying all the time displays, and then rewriting them according to specified locale.
$('.time')each(time_locale_preference)<span className="time">{props time}</span>
With React, somewhere in the component chain, the time locale would need to be coded for
<span>time_locale_preference(propstime)</span>
The concept of allowing the view to change apart from the control of React is not a foreign concept. In a way, css does this. Changing the properties of a css class can change the display of a React component without React logic knowing or caring.
This can all be seen as a chain of which data and how it is displayed
- backend | all data | as DB
- front end state | subset(all data) | as JS
- react components | subset(subset(all data)) | as HTML
- CSS render | subset(subset(all data)) | as rendered HTML
At the front end state level, no one protests formatting changes at the React component level b/c it doesn’t affect the front end state.
At the React level, no one protests against changing CSS b/c it doesn’t affect React logic.
You can add an additional HTML transformation, between #3 and #4, without upsetting logic at the React level.
- backend
- front end state
- react components
- HTML enhancer code
- CSS render
However, there are various problems to jQuery enhancements:
- testing scripts would need to change to encompass these modifications
- React re-rendering would have to integrate with post React render modifications
- the HTML will be displayed unenhanced until the enhancement code completes
- bad design would allow enhancement logic to change state data
The DidUpdate functions would have to call the enhancement for their particular element. The enhancer would have to re-enhance unenhanced elements. And, the enhancer would have to keep track of which elements became unenhanced (sinct an React update wouldn’t necessarily mean all enhanced elements reverted)
The complexity of requirements for this would benefit from a standard.
Example enhancement potentials:
- tooltips
- form field enhancement
- JSON editor
- date time input field enhancements
- form csrf
- table logic. Imagine if you did not have the built in logic of the browser that controls dynamically change wdith and keeping table columns equal. This sort of set assessesment must be done {1, ouside of a component (row or column item)} and {2, with review of rendered content size}. I’ve needed to do something similar to this with element width matching.