Open housseindjirdeh opened 7 years ago
I like it! As just a minor phrasing thing, I think it might be better to use button.style.js
instead of button.styled.js
(obviously very minor and unimportant).
^ Nope that's definitely important, and I agree :)
I like this a lot!
Just to avoid confusions as the notifications section currently only contain one screen, how would src/user
and the 4 screens it contain be adapted? Would it be one root folder per screen?
screens/
āāā user-followers-list/
āāā user-following-list/
āāā user-profile/
āāā user-repositories-list/
<3
Yep @machour that's exactly what I was thinking . Right now we have a number of screens within user
currently and they could all be in their own separate directories like this:
components/
āāā button/
āāā badge/
āāā // ...
screens/
āāā notifications/
āāā user-followers-list/
āāā user-following-list/
āāā user-profile/
āāā user-repositories-list/
āāā // ...
With this structure, it will mean we'll have to split user.action.js
to 4 different unique action files (and the same with user.reducer
and user.type
). It's going to be more work but I think the granularity will only make things better.
If a screen means it's a container that maps to our state, then automatically make it have it's own root folder. If it's a low level component that doesn't map to state, we throw it in the components
directory.
Our folder structure has changed as things have progressed and I'm thinking of another pattern we can start moving towards. I think having a folder structure for every component might be something we need to move towards. For example, our low level components in
components/
And our container components (our "screens")
With this pattern each of our components will be purely JSX renders that accept props. A container file like
notifications.container.js
will be something like the following:Keeping this logic separate from the actual component file means the actual notification component file does not represent any specific state logic. It just takes props, and the container is responsible for mapping those props to states and actions. In this example, also taking advantage of recompose.
mapDispatchers
can also be a utils method that leveragesbindActionCreators
from redux.This is a pattern a lot of my colleagues here at work are using and I'm really starting to see the benefit. Will love to hear everyone's opinions š¬