Product component

[cole-sanderson]

This PR adds the Product component.

Product component is built on top of vellum (add-vellum branch).

There is no style for this component, its more for product component markup. But if you think there should be some basic style for this component, let me know.

Status: Read for Review Reviewers: @kpeatt @ry5n @jeffkamo @mlworks @nastiatikk @avelinet

[ry5n]

(Really high-level comment here, only because this is the fist “big/composite” component we’re adding here.)

I think we should avoid making these composite components fit all use cases. It’s too hard and if successful will likely produce something very heavyweight and hard to use. I think these should be seen as something that will work in the most common case, and be seen as a “recipe” for those who are looking for direction but have more specific needs.

As such, I think we almost need a “basic” site design – like an actual set of mocks and/or wireframes that define a cohesive “typical” site for us that we can build components for.

What do you think @jeffkamo @kpeatt @tedtate?

[cole-sanderson]

@ry5n Yeah, I agreed, I think this component will be complicated to use because it depends on design. I dont think this component belong to Stencil because Stencil should have all basic components. Or maybe this component will need to be written in different way? I had mixed feelings when I was in middle of developing this component because I dont think this component meet Stencil's expectation to keep it simple.

Maybe we all should sit down and list components that will belong to Stencil so benchy devs can work on it.

[avelinet]

Good points @ry5n. I agree it seems futile to try and build a composite component that will work for all use cases. I like the idea of basic components that provide a recipe or starting point and that could be further customized. In that case though we would have to revisit how we include the components in a project.

We also threw around the idea of having multiple variations of a component to fit different use cases. @jackygilbertson had mentioned designers could do some mocks or wireframes of various versions of a component. Maybe we could find a place where those could live so that devs would know where to find them and build them out when they have some bench time.

[ry5n]

I think this still belongs in Stencil. I just wanted to make sure we’re on the same page that we want to make some common big-picture patterns very easy – especially for some types of builds where design hours are slim to none – rather than coming up with one implementation to rule them all.

Apologies @avelinet & @jackygilbertson I totally spaced on that – your suggestion at the last meeting is totally a good way of doing this (with multiple versions implemented and you pick the one that best fits the immediate situation). Not sure exactly how (all different class names? same class name but you’re expected to use only one one a project?), need to figure that out.

[avelinet]

@ry5n I think different class names would be best so that there would be the flexibility of using more than 1 version of a component in a project if for some reasons there was a need for it.

[ry5n]

@avelinet I think you’re right. Other way seems really fragile.

[kpeatt]

I think we could follow a similar base/modifier method that we use to naming our components for variations. Agree that there should be a 'base' design for components moving forward — ideally mostly expressed through changeable variables.

[jeffkamo]

Yup, I'm on board this. Having a single class for each variations for sure.

Not that we need to pin all variations right now, but for sake of clarity and example, what sort of product variations might we see? And as such, what classes would they look like?

Using Kyle's example above, I suppose we might see...

c-product covers most e-commerce websites. c-product-reservation which could have a unique layout in a different order than the standard product. c-product-fixed-cta product pages that have a need for a fixed CTA. c-product-multi is perhaps a rare use case, but we have done this one time before.

Is this the sort of direction we are considering?

[ry5n]

@jeffkamo That seems more like different components than what @kpeatt is talking about. I’d actually be more comfortable with multiple components than with a single component + variations. It allows them to be less tightly interdependent, which I think we’ll probably want.

Wondering if we should open a new issue to continue this discussion?

[jeffkamo]

Sure, I made ticket #115 to continue this discussion.

[ry5n]

I think we made a lot of good progress here and surfaced a lot of great problems we’ll need to tackle, but I think we should tackle those in Stencil 2.0. Right now we’re working our way up to things that are more complex (like this) from smaller things (like stencil-select).

So, thanks @cole-sanderson for kicking things off, but I’m going to close things off here.