Dzintars 2:33 PM
Hi. So, basically i understood the concept and got it working. However, would like to ask which is the right place to import connected element so it's get registered? Currently i do import it at view component level alongside with non-connected element. Also, do you separate booth component types in separate directories like /containers for connected components and /components for non-connected (representational) components ar you don't bother with such organization and place all components in single directory?
ccm 6:36 PM
it depends on the nature of the project, but for more serious apps I like to have a pure components-only project which is just the building blocks, no redux or other state. It means all the dependencies are purely for the components. These components are then dependencies for the apps (often more than one - like a user-facing site plus backend admin tools etc… which is another reason a separate repo for them is useful). The app has the connected views / container elements so there isn’t usually any need to split them within the same project
6:37
The separation also helps reinforce which things should be state-store connected and which should be pure components (using properties + events). I found working with junior programmers they would often want to just reference the wrong things in the wrong places and this helped force the correct structure (edited)
Dzintars 6:38 PM
Interesting. Understood. Will try to experiment with this in the coming days. :slightly_smiling_face:
6:42
I think webpack 5 workspaces could help there to separate "projects" and yet to handle component imports for local dev. Pushing everything to the npm registry just for imports would be kinda slow. Anyway... thank you for the hint. Will try to do this with single component/feature.
6:42
Or Lerna
6:43
will look into those
ccm 6:48 PM
you don’t need to push things to npm for local use, just use npm link
Dzintars 6:49 PM
Ok. Will look into that
6:49
Never used
ccm 6:52 PM
for the times you do need to do some integration before publishing, it can be useful. But usually if you focus on getting the building blocks created first, then you just switch to working at the higher level on the app side where you are using them in the views. Again, junior devs were always thinking in terms of building the one whole thing, and their testing was always “run the app” … it’s better to be more disciplined and create + test the components and only then work on the views - so the need to have it all connected all the time isn’t as important as you imagine (until you’ve tried the alternative)
Dzintars 6:56 PM
:slightly_smiling_face: Understood. Good point. You are describing me. I am trying to build the whole thing including the back-end API just to get "real data" fed in. :slightly_smiling_face: And then to see whole app running. :slightly_smiling_face: I understood what you are talking about... will try to re-think my workflow. Thank you very much of spending time for me. :slightly_smiling_face: (edited)
ccm 6:57 PM
it’s way easier to create test scenarios for elements with dummy data to show all the different states a component can be in, vs doing it with a running app
Dzintars 6:57 PM
Basically i should focus on "placeholder" data... which means i can separate projects like you said. And work component by component in isolation. (edited)
ccm 6:59 PM
yes, and I also find it’s easy + useful to create image captures of the components in different states - these can be useful as a visual library of the building blocks and are useful when thinking about the UI design part (they should match the designs created in something like XD) (edited)
Dzintars 7:00 PM
Nice. I have a lot to think about/learn now... Thank You! :slightly_smiling_face:
7:00
Have a nice weekend! :slightly_smiling_face:
:+1:
Dzintars 2:33 PM Hi. So, basically i understood the concept and got it working. However, would like to ask which is the right place to import connected element so it's get registered? Currently i do import it at view component level alongside with non-connected element. Also, do you separate booth component types in separate directories like /containers for connected components and /components for non-connected (representational) components ar you don't bother with such organization and place all components in single directory?
ccm 6:36 PM it depends on the nature of the project, but for more serious apps I like to have a pure components-only project which is just the building blocks, no redux or other state. It means all the dependencies are purely for the components. These components are then dependencies for the apps (often more than one - like a user-facing site plus backend admin tools etc… which is another reason a separate repo for them is useful). The app has the connected views / container elements so there isn’t usually any need to split them within the same project 6:37 The separation also helps reinforce which things should be state-store connected and which should be pure components (using properties + events). I found working with junior programmers they would often want to just reference the wrong things in the wrong places and this helped force the correct structure (edited)
Dzintars 6:38 PM Interesting. Understood. Will try to experiment with this in the coming days. :slightly_smiling_face: 6:42 I think webpack 5 workspaces could help there to separate "projects" and yet to handle component imports for local dev. Pushing everything to the npm registry just for imports would be kinda slow. Anyway... thank you for the hint. Will try to do this with single component/feature. 6:42 Or Lerna 6:43 will look into those
ccm 6:48 PM you don’t need to push things to npm for local use, just use npm link
Dzintars 6:49 PM Ok. Will look into that 6:49 Never used
ccm 6:52 PM for the times you do need to do some integration before publishing, it can be useful. But usually if you focus on getting the building blocks created first, then you just switch to working at the higher level on the app side where you are using them in the views. Again, junior devs were always thinking in terms of building the one whole thing, and their testing was always “run the app” … it’s better to be more disciplined and create + test the components and only then work on the views - so the need to have it all connected all the time isn’t as important as you imagine (until you’ve tried the alternative)
Dzintars 6:56 PM :slightly_smiling_face: Understood. Good point. You are describing me. I am trying to build the whole thing including the back-end API just to get "real data" fed in. :slightly_smiling_face: And then to see whole app running. :slightly_smiling_face: I understood what you are talking about... will try to re-think my workflow. Thank you very much of spending time for me. :slightly_smiling_face: (edited)
ccm 6:57 PM it’s way easier to create test scenarios for elements with dummy data to show all the different states a component can be in, vs doing it with a running app
Dzintars 6:57 PM Basically i should focus on "placeholder" data... which means i can separate projects like you said. And work component by component in isolation. (edited)
ccm 6:59 PM yes, and I also find it’s easy + useful to create image captures of the components in different states - these can be useful as a visual library of the building blocks and are useful when thinking about the UI design part (they should match the designs created in something like XD) (edited)
Dzintars 7:00 PM Nice. I have a lot to think about/learn now... Thank You! :slightly_smiling_face: 7:00 Have a nice weekend! :slightly_smiling_face: :+1: