Stencil components prefixer

[nastiatikk]

Now when we have quite a lot Stencil components and gonna have more it may become harder to distinct them from project components. Especially if they collaborate with each other. Plus it's never clear if it's a Stencil or project component modifier.

What do you think of the potential prefixer change for Stencil components. To s- to identify it's a Stencil or to u- (cause partly it's also a utility).

I see issues with prefixing it with u- cause it will be mixed with the small utils plus it's not 100% utils (though it's still utils at least in the way how we use it).

Well, here is a thought. Thoughts? @kpeatt @jeffkamo @ry5n @avelinet @yourpalsonja @mlworks @cole-sanderson

[jeffkamo]

what's "ща еруь"?

[nastiatikk]

Haha it was an accidental typo

[jeffkamo]

I feel that we should not use s- as a stencil prefixes, because these classes must be overridable with the classes we define in our own /components directory which use c-. I also don't feel there's an issue with findabilty because we should all know that if you can't find a class definition in /components then it's in Stencil.

So no, I do not think that there is a need for an s- namespace.

As for the matter of u- I feel that there are some stencil components that we use less like the other components and more like utilities. For example, c-arrange get's used more like a utility. I understand that @ry5n had a particular philosophy that defined how that component was created and why it's a component, but so far it doesn't match it's practical usage. For example, we mix it in with markup that needs some structure that we don't want to write new CSS for, but we never add styles to it, which is something stencil components are intended to receive (new styles).

So I would be interested in discussing the possibility of re-name-spacing some of the components to be utilities.

[ry5n]

I agree with Jeff, I don’t see the need to add a new namespace for Stencil components. I’m open to discussing whether some components should be re-classified. Specifically re: Arrange, it’s more complex than most utils so if we did make it into one it might need changes.

[jeffkamo]

What sort of changes do you forsee having to happen if arrange were to become a utility?

[ry5n]

@jeffkamo Well right now, utils do not have modifiers or sub-components. Arrange does. Utils are conceived as ways of applying low-level styling (at the level of one or a few css properties) to a single element. I guess I was thinking you could have u-arrange and then a bunch of utils for controlling alignment and such. But now that I’m thinking it through that’s not workable because you need modifiers for gutters and so on.

I would be happier keeping it as a component for that reason.

[jeffkamo]

Good point about the gutters. Maybe that should be its own component? Perhaps too, the arrange sub-components should be their own utilities? Not sure if that makes sense... Something like...

// arrange
.u-arrange {
    display: flex;
    flex-direction:
    // etc.
}

// Align Items
.u-align-items-top {    
}

// Justify Content
.u-justify-content-start {
}

// etc.

Perhaps that's getting out of hand? But again, this is effectively how we've been using the existing c-arrange classes in our projects.

[ry5n]

Separate utils was what I was thinking but gutters make that not feasible. The way gutters are (and should be) implemented requires coordination between the parent element and the children. It must be a composite style pattern. Whether that deserves the name “component” or not is the question.

Not sure if it scales, but in this case we could consider an l- prefix for layout patterns like this. Their stylesheet would look like a component but the idea is you’d just apply the classes yourself and it might feel less weird when they overlap with other component classes.

[ry5n]

Or we could just expand what utils are to cover this kind of case.

[jeffkamo]

Hmm... are there any serious downsides to expanding what utilities can cover? Would that be opening it up to become a dumping ground for any class that isn't a "component"?

On the other hand, it's not completely inconceivable that we create another namespace... we did that for u- originally, we could do it again... but should we? My gut says no, as we already have so many.

[nastiatikk]

I't say that utils describe themselves - they are utility items, helpers. Components are not helpers, they are page elements. Arrange is a helper to place elements on the page (or in the element), ratio is a helper to place media on the page, grid id a helper to place elements on the page.

[ry5n]

@nastiatikk Pretty good description. Yeah, I can see us expanding the definition of what a util is. Probably preferable to a new namespace. I need to think about it some more.

We can probably close this issue though – I think we agree no new namespaces for now.