dobtco / dvl-core

Base styles for the DOBT View Layer.
https://design.dobt.co/
1 stars 1 forks source link

Make this repo as small as possible #1

Closed jrubenoff closed 9 years ago

jrubenoff commented 9 years ago

For discussion:

I should never have to PR to more than one repo to change a UI component. Every permutation of a component's markup, styling and JS should be encapsulated in a single codebase.

Following that logic, dvl-core should only contain styles relevant to the entire application, rather than styles for just one or even a few components. This would include:

This means modals, tooltips, sidebar styles, etc. should go into their own separate repos. Also, we take out any default styling for elements we override in another component.

Thoughts?

ajb commented 9 years ago

Sorry, didn't see this until now.

I should never have to PR to more than one repo to change a UI component. Every permutation of a component's markup, styling and JS should be encapsulated in a single codebase.

100% agree.

But I'm not sure that moving out the "common components" will help accomplish this. I was actually thinking about this the other day, and I don't see what's wrong with keeping so-called "common" components (components that would theoretically be used in almost every application we develop) inside of this one repo.

jrubenoff commented 9 years ago

Hm, I guess it's more of a style thing. Basically, I want to make Web Components without actually using Web Components, with a very rigid enforced encapsulation. It should be crystal clear which repository you need to edit to make a code change: either you're editing global styles in dvl-core, component styles in dvl-component, or page-specific styles in the app's repo.

Also, if we are taking a multi-app approach to this, there are many reasons to work towards making this repo smaller rather than bigger. If we're prototyping a redesign with new or radically modified components, we can swap those in while retaining our core styles and helper mixins. Down the line, if we want a new app to have different branding, we can just switch out the color variables while retaining everything else.

ajb commented 9 years ago

Basically, I want to make Web Components without actually using Web Components, with a very rigid enforced encapsulation

:+1:, so our "Outcome" is the same :grinning:

It should be crystal clear which repository you need to edit to make a code change: either you're editing global styles in dvl-core, component styles in dvl-component, or page-specific styles in the app's repo.

Aha, so you want all global styles in here, but all components go inside dvl-component? I hadn't thought about this possibility before.

I think some of concerns might be solved in other ways. My mindset has actually changed a little bit since I originally created the dvl-flashes repo. I think we should consider putting all of our shared view components inside of the dvl-core repo, but that they can be selectively imported in their host app. Let me explain: Right now, dvl-flashes depends on dvl-core for resets & base styles. Theoretically, dvl-component as you've described it would also depend on dvl-core for the same reason. What's the point of having two separate repos if one is dependent on the other?

If we're prototyping a redesign with new or radically modified components, we can swap those in while retaining our core styles and helper mixins.

I think we can achieve this by simply adding a components directory here. In the host app, which currently looks like:

@import 'dvl/core';

We could change it to say:

@import 'dvl/core';
@import 'dvl/components';

Or we could even be more selective:

@import 'variable_overrides'
@import 'dvl/core'; // these variables use !default so they're overriden
@import 'dvl/components/modal';
@import 'dvl/components/button';

Essentially, I think that everything you're talking about can be achieved at different level than "make separate gems", which as we've discovered, can be kinda time consuming and problematic.

Anyway, I feel like we're close to agreement, so I'm happy to hop on a hangout (maybe after the weekend?) to hammer out some of the remaining finer points. Let me know what I missed :P

jrubenoff commented 9 years ago

Sorry, I was referring to our current dvl-flashes-style naming structure. Should have written dvl-[component name].

Anyway, I think you changed my mind. Theoretically I still think separate gems are the way to go, but if I'm wrong, the consequences are much worse (having to re-bundle many gems with every change) than if we just keep them in the same repo. So let's go for it.

ajb commented 9 years ago

Cool! I'll get dvl-flashes in here soon, then!