feature-driven-architecture icon indicating copy to clipboard operation
feature-driven-architecture copied to clipboard

Define a feature

Open kof opened this issue 7 years ago β€’ 2 comments

kof avatar Nov 29 '18 23:11 kof

OK this architecture looks promising πŸŽ‰ i started implementing it in my projects and it really helped and boosted πŸš€the speed of my development but lets start a discussion so we all learn something here.

TLDR A two features still two until they need to share some data between, and they become one?

when it comes to defining a feature i find it a bit ambiguous where that boundary should be drawn, as you mentioned in your Berlin talk,a feature is a user front facing piece of enclosing logic that do not affect other features directly so it is disposable, co-located, ...etc, and that leads to the core of drawing that boundary in any application is to recognize those pieces of UI groups that works together having inside them the UI, the logic, the data. But when two features have some shared data between them, the rule is they should talk through their container the Page they live into, so the rule for defining a feature here becomes to draw the boundary around enclosing piece of data and that defines the feature.

  • can a feature exposes some internal state that other feature depend on to?
  • how can we apply this architecture in back-end apps does the data model becomes the feature ?

I am mostly wrong and I'll be happy to read some different points of view Thanks to any one will share their thoughts 🌹

hassanhe avatar Jan 18 '19 19:01 hassanhe

First look

Core concepts (and question) of feature:

  • Isolation: feature don’t depend on another feature
    • but if we get another feature from render props (from page), it’s ok?
  • Public interface and private exports
  • Feature can use components and utilities from public
    • or we should pass it from the page?
  • Feature should contain all things for work with store. for redux it can be actionTypes, actionCreators, selectors, sagas, reducers etc.
  • Feature should contain components and containers, that are only used in it

Ideas about feature directory structure

feature
|__ renderers
|__ containers
|__ store
|__ index.js
|__ Readme.md
  • store folder for the reducers, actionTypes, actionCreators, selectors etc.
  • add __test___ folder into the renderers, containers, store folders
  • add index.js to the renderers folder, to avoid long imports list in the containers like that:
import Component1 from β€˜../renderers/Component1’
import Component2 from β€˜../renderers/Component2’
…
import Component10 from β€˜../renderers/Component10’
  • in the folder renderers we can create folders for some components, for example if we need add .svg logo file:
feature
|__ renderers
|____ Component1.js
|____ Component2.js
|____ Header
|______ Header.js
|______ logo.svg

or we should add in the feature folder images ?

pgrekovich avatar Mar 18 '19 10:03 pgrekovich