Core modules[proposal, discussion]

Hi! For now we are using core components and pages to develop our stores which works well but have some drawbacks that can be fixed:

• The functionalities are grouped in component-structure-oriented way rather that feature-oriented which is not the best approach for a modular application
• It kind of forces people to use same component structure for each store which doesn’t play well with implementations that are much different than our default theme
• Core components are rather complex, it’s hard to reason about them and even harder to change only the parts that we want to work different
• People can’t tell what are the features of the component just by looking at it - you need to jump into the code and understand it
• Methods inside core components are tightly copupled which isn’t good for refactoring and modifying some functions in the future
• It’s hard to reason what comes from core and what comes from theme if both are bulky and complicated
• We are injecting whole components even when we only want one or two features which ends up as bulky components with redundant functionalities
• You basically can’t say what you can do with the core without understanding it in-depth
• its nearly impossible to tell people which functions are part of the CORE API so they can rely on them and use in their themes and which are just helper functions

What is the proposed fix?

The idea is to group similar functionalities into modules. Also I’ll try to split current core components into smaller standalone features (like add to cart, remove from cart, items in car etc). it’s still meant to be used as mixins but now you will export exactly what you want and will know exactly what you are injecting

You can find two proposal modules here ( https://github.com/filrak/vue-storefront/tree/modules-and-catalog-theme/core/modules )The implementation of this particular modules will (for sure) change but it’s just to get the idea.

So now instead of bunch of core components for let’s say cart we will have cart module with following mixins to import: cart_add(product), cart_remove(product), cart_items, cart_isInCart(product) etc. So we can for example import only cart_isInCart() mixin to our product listing to tell the user that this item is in cart. Now we will need to import whole microcart module or copy this method from inside of the core to achieve this.

The proposed API for using it will be as follows.

modulePrefix_methodOrDataname - so you can see from the beginning in your theme’s code that this functionality is a core functionality coming from module X.

1. You can import all parts of the module (including every data property and method related to this module) and inject:

import CartModule from 'core/modules/cart'
...
mixins: [CartModule]

2…or just the ones that you need (this particular set would be useful for Product page)

import { cart_add, cart_remove } from 'core/modules/cart'
...
mixins: [cart_add, cart_remove]

Similar modules would be created for wishlist, menu, categories, product, compare etc.

Such modularisation and abstraction will also hide the helper functions so we can refactor and improve our core much efficient without bothering about all legacy code and focusing only on keeping the core exported functions untouched with its API

Ofc we can still have some core components that will just group features from one or many modules that are commonly grouped together but it would be a little help and addition to speed up some very common taska, not the core itself that we must always use.

The core pages with their core functionalities will probably stay as they are with small refactoring but this one is still to be discussed (probably having 3-4 pages like this will be still transparent for developers)

Please let me know what do you think about this API, how do you see the improvements and what else can be improved during this API change.

You can find previous discussion here: https://github.com/DivanteLtd/vue-storefront/pull/1184

[michael-kaufman]

As someone 2 weeks into this code, I agree and like the Modular approach. It does get rather tricky to know what comes from where exactly. Having duplicate folder names in different places is a little confusing too. Perhaps refactoring folder names to make it clear for e.g. core-logic vs core-theme or plug-in-logic vs plug-in-theme; or something similar would help too. Thanks!

[filrak]

@pkarw i edited a little bit my first post yesterday. The idea is to still keep some of the core components:

“Ofc we can still have some core components that will just group features from one or many modules that are commonly grouped together but it would be a little help and addition to speed up some very common taska, not the core itself that we must always use.”

So for example we will have cart api module with methods i listed above but you will still have microcart core component as a set of grouped functions to handle some common behavior but, what si important, you are not forced to use it and the logic for helper functions is hidden from you so it can be improved and refactored without breaking the api. The core microcart can look more or less like this

import { cartAdd, cartRemove, cartItems, cartTotals, cartSubtotals } from 'core/api/cart'
import { checkoutGoTo } from 'core/api/checkout'

export default {
  mixins: [  cartAdd, cartRemove, cartItems, cartTotals, cartSubtotals, checkoutGoTo ]
}

With this approach core components will group the core api methods so it’s still very easy to create common components but we are avoiding repetition of code (similar functionalities on different components) and we are hiding the code itself so we can upgrade it, delete/rename/modify functions that are not exposed for api (helper functiosn) etc.

Abstracting the data and method properties that can be used by develoeprs is crucial for me in case of upgradability. For now we have no idea what methods from core components people are using so we can’t really tell which one we can refactor and change. With modules it will be much easier (the core/api name is much better tho - thanks @Triloworld ).

@nuovecode yes, simplicity is very very important but i don’t think you will loose anything with abstracting this API into modules. This modules still can be grouped into pages or components but at least there will be way to use only features that you want in a way you want instead of injecting component with 10 methods to use one of them. We need a higher level of granularity.

It will be also great for test purposes since we can just test every method separetely.

Now the API is very easy to work with but the goal of this change is to keep it as simple as it is but more readable, more upgradable, less complicated (developers don’t need to know everything about how core component works to use it, in most cases the name is self-explainamble) and, what is most important for me, more scalable and flexible.