It's almost a necessity for complicated apps. Right now I'm building an app which involves a reporting screen with all the following features on a single page:
- 10+ breakdowns for report
- 10+ filters for report
- Each filter has an include/exclude dropdown list which then has multiple features within even a single filter (so some filters are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for each filter, not to mention clearing filters, etc
- column sorting
- column hiding
- filtering with search
- pagination on both client and server side (50K rows batching into sub pagination groups which client side takes over on server batches)
- a dropdown at the top which re-initializes EVERY piece of data with a different account and changes quite literally re-initializes 50+ "states" of the UI on the page
Thinks of google analytics
First of all, we can assume doing this on the front end is 100% required. Imagine using google analytics where every single option you change is a backend request. Impossible, so now that weve gotten past that...
Imagine using something like jquery or custom JS where you try to manage the incredibly complicated input/output nature of each component of the page.
Component based design is required because you can keep all your logic for the entire app for a single TINY piece of the app in its own file. So something like a dropdown menu can get its own component called `<DropdownMenu>`, and within that you define all "outer state" that component can use as a prop, or input state (so for example, you want the items that appear in the list to be defined OUTSIDE the component so the component can be re-used). However, that component also has its own internal state, such as whether its open or not, whether its animating or not, what item is selected etc, so if a component has internal state, then you store it IN the component itself. So now the 'state' of EVERY component on the page is defined in 2 places... the originator of the state (such as the component which holds your API calls), or in the component itself. When any change takes place in ANY of those states, all components related to that state "update" automatically to use that new state. This means by simply making a new API call, the outer component state changes, and every single component that relies on that state updates accordingly, even for the most complex UI imaginable its trivial to think about 95% of the logic because all the state is exactly where you expect it to be, and when there are infinite numbers of nuanced side effects, you usually program them IN the component and you dont have to clutter your actual logic (say for instance the api updates your base state, you want the dropdown to reset to zero, so you would code this into the component itself, so that everywhere on the page that uses this component it would all follow suit).
What do you mean by 'templating engine'. Give me a specific example. Templating engines to me are like handlebars... do you have a sample code example?
Yes, you are definitely missing the point of component based frameworks. That strategy is not even remotely scalable when you have nested complex state chains that vary slightly across multiple implementations of the same component, as well as 2-way communication with the original source of the state (from form inputs, and other parts of the UI).
Each UI action in google analytics affects some other part of the UI. If you change a filter in one area, it might disable sorting in another, and simultaneously change the calendar to be only < 1 year. It might also disable some setting portion of the UI, reset the chart, change the input option on the chart axis, and then show a text input you can type in, and when you type in it, ALL THE previously mentioned states now react to the input box that appears.
You want the logic for those components to be IN THE COMPONENT. With your strategy youre putting all NON business logic and trying to account for "every possible scenario" which is the exact purpose of what reactivity does. You're not writing 1000 extra lines of code to account for every single possible combination (which can be hundreds in complex apps). Instead you quite literally write 0 lines of code, because the reactivity is handled (both ways)
- 10+ breakdowns for report - 10+ filters for report - Each filter has an include/exclude dropdown list which then has multiple features within even a single filter (so some filters are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for each filter, not to mention clearing filters, etc - column sorting - column hiding - filtering with search - pagination on both client and server side (50K rows batching into sub pagination groups which client side takes over on server batches) - a dropdown at the top which re-initializes EVERY piece of data with a different account and changes quite literally re-initializes 50+ "states" of the UI on the page
Thinks of google analytics
First of all, we can assume doing this on the front end is 100% required. Imagine using google analytics where every single option you change is a backend request. Impossible, so now that weve gotten past that...
Imagine using something like jquery or custom JS where you try to manage the incredibly complicated input/output nature of each component of the page.
Component based design is required because you can keep all your logic for the entire app for a single TINY piece of the app in its own file. So something like a dropdown menu can get its own component called `<DropdownMenu>`, and within that you define all "outer state" that component can use as a prop, or input state (so for example, you want the items that appear in the list to be defined OUTSIDE the component so the component can be re-used). However, that component also has its own internal state, such as whether its open or not, whether its animating or not, what item is selected etc, so if a component has internal state, then you store it IN the component itself. So now the 'state' of EVERY component on the page is defined in 2 places... the originator of the state (such as the component which holds your API calls), or in the component itself. When any change takes place in ANY of those states, all components related to that state "update" automatically to use that new state. This means by simply making a new API call, the outer component state changes, and every single component that relies on that state updates accordingly, even for the most complex UI imaginable its trivial to think about 95% of the logic because all the state is exactly where you expect it to be, and when there are infinite numbers of nuanced side effects, you usually program them IN the component and you dont have to clutter your actual logic (say for instance the api updates your base state, you want the dropdown to reset to zero, so you would code this into the component itself, so that everywhere on the page that uses this component it would all follow suit).