If you need to do it, do it, if you don’t, don’t. This seems simplistic advice, but it’s not really possible to give you detailed advice without seeing code examples.
It is easier to understand programs if they are
- simple, and
- in one file.
As a rule the more files you have, the more difficult it becomes to navigate and edit. The more complex the logic in individual files becomes, the more difficult it becomes to understand and debug. The longer the individual files become, the more difficult it becomes to navigate and understand the flow of the logic.
Also, the more complex a single unit is, the more difficult it becomes to test and debug. But for things to be useful they often need complexity, it is the wrong move to over-generalise and over-abstract.
The easiest way to deal with this kind of complexity is often to split the bits of UI logic into different files/components. But this is completely context sensitive and shouldn’t be done for the sake of doing it. It’s an abstraction, and premature abstraction is dangerous. It may well reduce the complexity of individual components, but you then have a number of components that need to link to one another somehow – you are possibly just trading one type of complexity for another.
It’s fine to break any of these rules, and in practise that will almost always happen (as an example, it would make sense if you were writing a markdown parser to make it a single complex function).
You have a function that takes some text input and passes it through a markdown processor to generate some output. You’re using React to flatten the complexity of the UI down to a handful of functions that you call, and you’re using the markdown parser to flatten the complexity of parsing down to a single function.
If it lives in a single component, dealing with state becomes a lot easier because you don’t have to pass anything between components. It also colocates all of the code, so there is no navigating between files: everything that works together in the UI lives together in the same place in the code.
On the other hand, if you split out the components, they become much easier to unit test and may be easier to reason about.