You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to discuss module structure of the project. There are 2 different ways of organising packages: horizontal and vertical. The difference described here http://meanjs.org/docs/0.3.x/#angularjs-modules.
Looking to the packages like reaction-schemas, reaction-collections, reaction-factories I see horizontal way of modules structure. But to my mind, working with Django Framework and many others since 2009, I dare say, that vertical way is much more practical and comfortable. For example, while implementing package reaction-flat-pages I found that in case of merging this package to the core and following the current paradigm of modules structure, it would be necessary to split this package and put collections to reaction-collections, factories to reaction-factories etc. But I prefer to too keep all parts and functionality of this package in one place and keep this package pluggable and independent from the core.
The same reasons lead meteor team to splitmeteor-platform into smaller packages meteor/meteor#4851
Looking to the structure of reaction-core I always think about decomposition it to the small pluggable packages, for example: reaction-products, reaction-products-variants, reaction-products-tags, reaction-cart, reaction-orders, reaction-packages, reaction-taxes, reaction-i18n, reaction-shops etc. And each package responsible only for little part of functionality and contains all necessary things: schemas, collections, factories, translations, tests and everything to be as much independent from others as it possible. In this case we would have flexible and comfortable configurable constructor for building any e-commerce platform we need. I can easily imaging use case, where we don't need cart and orders, but only products and contact form. Sometimes we need only one shop, sometimes marketplace with multi-tenant functionality (ebay-like). Sometimes we need product with variants, but I believe it should be extra-option with ability easy to switch it on/off, like we discuss here #500.
So, guys, what do you think?
The text was updated successfully, but these errors were encountered:
- moves cart and checkout templates from core into
`reactioncommerce:reaction-checkout`
- adds dependency in reaction-shipping to reaction-checkout
Related Issues:
- #731
- #451
- #416
I want to discuss module structure of the project. There are 2 different ways of organising packages: horizontal and vertical. The difference described here http://meanjs.org/docs/0.3.x/#angularjs-modules.
Looking to the packages like
reaction-schemas
,reaction-collections
,reaction-factories
I see horizontal way of modules structure. But to my mind, working with Django Framework and many others since 2009, I dare say, that vertical way is much more practical and comfortable. For example, while implementing package reaction-flat-pages I found that in case of merging this package to the core and following the current paradigm of modules structure, it would be necessary to split this package and put collections toreaction-collections
, factories toreaction-factories
etc. But I prefer to too keep all parts and functionality of this package in one place and keep this package pluggable and independent from the core.The same reasons lead meteor team to split
meteor-platform
into smaller packages meteor/meteor#4851Looking to the structure of reaction-core I always think about decomposition it to the small pluggable packages, for example:
reaction-products
,reaction-products-variants
,reaction-products-tags
,reaction-cart
,reaction-orders
,reaction-packages
,reaction-taxes
,reaction-i18n
,reaction-shops
etc. And each package responsible only for little part of functionality and contains all necessary things: schemas, collections, factories, translations, tests and everything to be as much independent from others as it possible. In this case we would have flexible and comfortable configurable constructor for building any e-commerce platform we need. I can easily imaging use case, where we don't need cart and orders, but only products and contact form. Sometimes we need only one shop, sometimes marketplace with multi-tenant functionality (ebay-like). Sometimes we need product with variants, but I believe it should be extra-option with ability easy to switch it on/off, like we discuss here #500.So, guys, what do you think?
The text was updated successfully, but these errors were encountered: