Cssectomy

[BnMcGn]

• Splits out hard coded CSS values into separate structures to allow complete removal or exchange per issues #183 and #51.
• Creates a set of utilities to simplify the merging of CSS from various sources.
• Provides a platform to work toward the remaining goals of #184.

Note to reviewer: Most of the meat of this rather large pull request is in util.cljs. Everything else is a rather repetitious application of the tools added there.

Thanks!

[mike-thompson-day8]

Just a quick sorry, because we have yet to look at this.
It does seem substantial and, therefor a bit scary.

[BnMcGn]

Yep, beware the big chunk! Thanks for looking at it. No hurry here.

[kimo-k]

Hey, thanks for all the effort you've put into designing this and maintaining the branch.

I've been over the PR a few times, drawing inspiration where I could. We've settled on a design which is not far off. The main differences are in ergonomics and levels of indirection:

• components accept a :theme prop
• A single theme can apply to all of re-com's components (or not).
• components also observe a global theme registry
  • the user can call reg-global-theme to theme their entire app at once.
• the registry separates themes by purpose:
  • :base - essential functionality, like :position "absolute", callbacks, etc.
  • :main - re-com's main aesthetic, stuff like :color "blue", spacing
  • :user - up to you.
    • :base-variables, main-variables, :user-variables: these add to the shared context, defining global concerns like spacing and color palette.
• a component can override or extend any registered theme.
• a theme is a function: props, context -> new-props, new-context.
  • A component should pass some initial context - part-id & state.
  • a vector of themes is a theme, too.
• for each part, we reduce all the themes to derive its props.
  • this could become an interceptor pattern if we need that
• We use merge-props & theme/apply in place of merge-css and add-map-to-hiccup-call.
• All this should make it possible for re-com to integrate with various style frameworks.
• meta/stylex, shadow-css, and modern plain css have been our driving examples.

I recently merged some of this work into our alpha components - see dropdown for a working example.

Would be great to hear what you think - specifically, whether you can imagine your tailwind project integrating with this design. It could be straightforward to factor each -css-spec into the default base and main themes, and adjust the component render functions to use theme/apply, or themed, a closure similar to your cmerger.

[BnMcGn]

Looks good!

First glance says definitely workable. I can probably eliminate re-com-tailwind as a separate project and just supply it as a re-com theme.

I think I have a few questions, but need to review the code a little more so that I know what I am asking :-)

[BnMcGn]

Things seem to be getting more complex, both in the component code and in the user options. Not surprising, with all the added features.

Here's something that might help: can the themes parameters to the component be simplified down to one :theme (or perhaps :themes) option? I like what you have done with splitting the theme into base, main and variables sections, but does the component need to know about them? There will be less cognitive load on casual users and component authors if the theme merging is done out of their sight. An advanced user who wishes to - say - reuse base and replace main can bundle them together, then pass the bundle in to specific components with the :theme option.

I should be able to look at rewriting the -css-spec stuff in a couple of weeks. I have another project to finish up.

[kimo-k]

Yes, we should do something like that.

When passed :theme my-theme-fn, the current naive behavior will conj your function onto the :user themes. That means at render time, re-com internally applies all the registered themes, and then applies my-theme-fn last. Does this match with your vision, or do you envision something else?

As for advanced usage, I should examine what I already wrote, maybe write some tests. I know it works to pass in :base-theme my-base-theme, which will replace re-com.theme.default/base with my-base-theme in the reduce. It could also make sense to pass in :theme {:base this-fn :main that-fn}, to replace multiple layers.

[BnMcGn]

Yes, probably, it should match what I'm thinking.

Honestly, I'm going to have to make another pass over your code. It hasn't all sunk in yet.

I was mostly reacting to the sight of the main-theme, theme-vars and base-theme keyword parameters of the dropdown render function.

[BnMcGn]

Should close this. Themes looks like the way to go.