I’m looking for better way to draw react components tree and share with team.
I tried JIRA but it’s spoiling format of tree structure, also team members not able to comment on particular child component or give suggestion properly.
Ideally it should work as props and state planner as well. It can help to decide which statement management library / technique I should use.
After starting to work with React project; I’m thinking more like a civil engineer e.g. what should be brick size, door, window, curtain size, shapes, water, drainage pipelines design LOL
It’ll be cool if we also have similar software to plan a building as civil engineers has
The map is not the territory: you can’t draw a 1:1 scale map of the world, it would be useless.
Don’t overthink it, use a pen and paper, with sticky notes or whatever. You’re going to throw it away multiple times, because you’ll get it wrong multiple times.
A general diagrammatic sketch is very useful, a high level overview. As are flow/state diagrams for specific parts of the application. The code and the tests for the code then are what you focus on.
There are class diagrams which would kinda work, but React is not a class-based OO system. There are sequence diagrams but they only deal with a sequence, you can’t realistically model an app with them. There are statecharts, which would work with the states being “screens” and the substates being the components of those screens but an entire system would end up being incredibly complex (a moderately featured login system is incredibly complex, never mind an entire application). None are ideal or deal well with reuse and composition. If you think you can specify all props and state etc, you’re likely on a hiding to nothing as much of that stuff is added to help with rendering things and loading data, and you either need to know exactly what will happen in every situation beforehand or you need to actually be writing code to figure that out.
There is also design prototyping software (Framer, Adobe XD etc) which is probably closest to useful.
Caveat to this: if you’re writing actual software for a sector that has extremely strict legal requirements, where you likely have to do this. Otherwise (and even in that case), the likelihood is you’ll spend all your time very carefully drawing up diagrams that don’t mean much.