I'm always curious about what the largest magnitude of a UI codebase someone has maintained when they make comments like this.
In particular: "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
If you want the most simple example, look at most apps based on bootstrap. They only start with the baseline/generated CSS, then apply hack patches throughout an application. Yes, you should use the source and generate yourself, for your application. But nobody does in practice. Even worse, a lot of the "bootstrap components" from third parties are also using hack css on top of the baseline, and require even more patches in actual structure.
I'm not bashing bootstrap, only pointing out how I've seen it used, which is poorly. Component based CSS in JS has even been a bit of an issue. Other developers on my team will put magic values into a given component instead of using values out of the theme that gets injected. I've had to go through again and again to correct this.
The difference is the former yields unexpected behaviors, while the latter is just a bit of inconvenience.
The former yields expected behaviors, and if you deviate, what do you expect? While the latter means that any time your product experiences a redesign, you have to manually change everything.
Not only do you manually change everything, and every component is isolated, you end up writing repetitive styles, and then you're stuck with a codebase with 5 different buttons, 4 different drop-downs, 7 different color schemes.
Nah, there's a reason why sites like Bootstrap Expo existed. CSS in JS doesn't just fail to prevent you from writing expensive to maintain code, it also makes it harder to evolve a product over time.
import baseStyles from './section.styles.js';
const styles = theme({
baseline: {
...theme.components.foo,
...baseStyles.foo,
// customizations here
},
variantState: {
// dynamically controlled style alterations for
// a different state
...baseStyles.variantState
},
});
export theme = async () => {
const {env, app, user} = getThemes();
return deepMerge(base.theme, env, app, user);
};Lets say you have a SaaS project with a couple hundred individual routes, and you count them as individual components, you still haven't reached the magnitude you're talking about.
To just jump to an example of an extreme case, Facebook has stated several times they have tens of thousands of components [0]. Now, I assume lots of folks on HN work for private companies that build a wide swath of applications ranging from trivial to massively complicated. Why is it outlandish to think people wouldn't have many components in an app?
[0]: https://www.reddit.com/r/reactjs/comments/6al7h2/facebook_ha...
This keeps complexity of render components relatively smaller. I also don't mind breaking up compositional components for say NumbericInput, IntegerInput, WholePositiveInput, WholeInput, etc for form fields, each one with some entry filters in the component, and state level validation elevated to the containing component (and ultimately through form events, etc).
Beyond a lot of this, you have components with some display variances (subheaders that are shared in a given section of an application for sub-navigation, and some informative display), Most displays in the application I'm currently working on have about 5 shared higher order components (route level, header, section subheader, page footer, page capture/composition, data rendering, form input), and about 10-15 smaller/nested components just for rendering about half shared.
Across the application so far, there are about 200 components, with the application about 30% complete. The application itself is using react-jss as it's the base for styling with the material-ui component library. I've tweaked what gets placed in the theme a bit to pass additional configuration items into the theme. Portions of these additional options are part of a release configuration (per client environment/deployment), and part from flexible application options that are loaded from the API when the application loads, configurable within the application.
I've done similar things with dynamically generating base.scss files, and frankly the CSS-in-JS is far more predictable and easier to manage compared to prior applications using Bootstrap or similar SCSS/Less component baselines.