Default Template 2.0 - feedback

We’re currently working on Default theme 2.0 - the design process is on its way. I think this is the right time to gather some feedback regarding code architecture/structure as well. This ticket is for that - please feel free to include Your voice in the discussion

What is the motivation/use case for changing the behavior or adding a new feature?

Default Theme in its current state is getting a little bit messy. After being one year in the business we also have some ideas how to make things simpler. On the design layer, on the other hand, we do have a lot of ideas on how to improve User Experience.

Tech feedback

Here we go with the ideas on how to improve the architecture of the themes

Too granular mixins

1. I think we should avoid a “two-liner” mixins like https://github.com/DivanteLtd/vue-storefront/blob/master/core/modules/cart/features/isMicrocartOpen.ts. These small mixins are very difficult to even discover by developers, the comment + brackets generate more lines than the core logic (which is just … .Vuex call). On the other hand, it makes the compile process longer (IO operation to import the module etc.). Moreover, it makes theme development more difficult (You have to create a lot of these mixins to meet good practices). I think we should keep things simple the core components were easy to understand and use for theme developers. If we’re to keep the features in module/features we should rather have kind of bundled mixins (with a set of features) - but this makes core components redundant.

I’m a fan of making things simpler and we should stay with core components + features that really do something (other than just calling Veux actions). Modules are a great idea but in this forms make a little good to the project. They make it more difficult to understand.

Current theme was thought of single/central theme without modularization as the scope of the theme is from my perspective too thin to divide it to modules (and the effects are these too granular mixins in my opinion).

We should aim more at WordPress/Shopify approach NOT Magento approach regarding themes.

Too complicated directory structure

1. We do have sth like:

• /theme/components/core/
• /theme/components/theme/
• /theme/components/core/blocks
• /theme/components/theme/blocks

We should simplify it - we don’t need blocks folder and probably don’t need theme as well. I think that the theme should be divided into sections corresponding to Pages and Components (maybe modules) + one “Common” folder - that’s all.

[mercs600]

Yo guys! So I agree with @pkarw default theme it’s getting messy. Generally we should start thinking more about functional/dumb components. But what we have now…

@pkarw

Too granular mixins

These small mixins are very difficult to even discover by developers, the comment + brackets generate more lines than the core logic (which is just … .Vuex call).

I know what you feel, but I agree absolutely with @filrak. From my perspective I would like to choose what I need use in my components than maintenance part of code which I don’t need. Comments are not problem because are not occur in build code.

Now we have small mixins where you can find just vuex call - right, but we never know what we will need to add to logic of these mixins later. We should keep some level of abstraction from Vuex. If we build some serious and simple documentation (https://vuejs.org/v2/api/ should be good example for us 😍) there will be no problems to find accurate mixin.

Now we give user core components build from feature mixins and this is great because he may take whole cart module with all needed logic. But again some of users may want to use only specific mixin and this is the point for us. Trust us 😉

Too complicated directory structure

We should simplify it - we don’t need blocks folder and probably don’t need theme as well.

I could not agree more with you. I think user may not know what is core component and what is theme component. I think blocks was nice idea, but we lost the track what it should be exactly 😄

@DavidRouyer

Can we rewrite components which have dependencies at the same time? For example, https://github.com/DivanteLtd/vue-storefront/blob/master/core/components/ProductGallery.js should be generic and not dependent of any dependency

Totally agree. New default theme or base set of components should be consist of only dumb / functional components. We shouldn’t keep the “data” logic in components like this. They should works only based on props.

@HRR1337

What about using TailwindCSS with Purgecss and ‘Above the fold CSS’? As fast as possible…

I’m not advocating for rely on some CSS frameworks in application such like VS. Stupid example with flexbox grid with some wrong padding calculation on mobile devices. We had a lot of problems to refactore current theme to flexbox grid 2 😰 because a lot of components was using flexboxgrid classes and what worse some part of our code overwrite default code of flexboxgrid - nightmare.

Few of my thoughts

1. We should pull out themes from our code base. Theme should be external package which user can maintain. Users should be able to update VS core without some hardcore merge.

2. Core logic components - we should give user all needed logic to create specific part of shop like cart, product page, checkout etc. I think we are on the good way with api features and core components like cart.

3. If we want to give possibility to simple and quickly customize we have to create some set of base theme components:

• These components should rely on css variables. Maybe we should think about css variables with some support
• We should strict define these variables, document and what’s important we should be consistent in using them.
• We should share some simple demo with theme components only - story book or something like this. In other words, we should create some simple design system.

1. In my opinion (perhaps only in my opinion 😁 ) we should avoid scoped styles. They are troublesome.

• For example you can’t override them in simple way from parent component because they creates some high css level selector.
• In large application they can impact on performance. Browser has to put more effort to target some attribute selector.
• The perfect solution is https://css-blocks.com/ but is it not implemented for vue yet. For me - best way is BEM, because this method allows you to create “flat” class selector and avoid problems with CSS specificity. I’m more favorable for solution such like this https://markus.oberlehner.net/blog/vue-application-structure-and-css-architecture/

1. We should start thinking about functional components - Theme components should rely only props. They shouldn’t get data directly from vuex or API. Data and logic should be provide page wrappers, in our case this will be product page / category page / checkout page. Dumb components will be helpful to improve performance, readability, scalability and testing.

to be continued…

[pkarw]

@jorkvist we’re all committed to fix v1 as well 😃