Okay, i've tried to think of ways to say this without coming off as harsh. I'm going to give pointed criticism and i promise my intent is not to "bash" you. I'm just going to give my honest take.
The Code
The code is bad, doesn't take advantage of implicit returns, hastily abstracts dependencies, makes decent integration testing fairly cumbersome because of the amount of dependency mocking you'd need to do. All in all, it would literally not pass code review, switch statements in a render function vs a hash map? This would get you paired with a senior for a few hours to fix this mess, it's that bad. It's a huge red flag. Too many code smells.
The Concept
The concept is a reasonable one for the backend where the "state" is usually colocated and composability isn't favored over inheritence. But it's just not great for the frontend. It's not composable, it's not easily maintained, it's not extensible, it's tightly coupled to your dependency setup, it's difficult to read, it's difficult to reason about, it's hard to test and therefore it should literally be avoided like the plague. It might actually be one of the worst architectures i've seen for frontend frameworks, including Anguler 1 (insider joke).
If your component/class isn't readable and you cannot discern what it's attempting to do in a short period of time, or extend it with confidence, in the tests/implementation, that it wouldn't break, it's not the solution to the problem.
This is the hastiest of hasty abstractions. Please never write code like this for the frontend. It's fun to see, but it's definitely not realistic or production worthy.
If this comes off as mean spirited, i promise that's not my intent, i'm trying to approach this in good faith.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Okay, i've tried to think of ways to say this without coming off as harsh. I'm going to give pointed criticism and i promise my intent is not to "bash" you. I'm just going to give my honest take.
The Code
The code is bad, doesn't take advantage of implicit returns, hastily abstracts dependencies, makes decent integration testing fairly cumbersome because of the amount of dependency mocking you'd need to do. All in all, it would literally not pass code review, switch statements in a render function vs a hash map? This would get you paired with a senior for a few hours to fix this mess, it's that bad. It's a huge red flag. Too many code smells.
The Concept
The concept is a reasonable one for the backend where the "state" is usually colocated and composability isn't favored over inheritence. But it's just not great for the frontend. It's not composable, it's not easily maintained, it's not extensible, it's tightly coupled to your dependency setup, it's difficult to read, it's difficult to reason about, it's hard to test and therefore it should literally be avoided like the plague. It might actually be one of the worst architectures i've seen for frontend frameworks, including Anguler 1 (insider joke).
If your component/class isn't readable and you cannot discern what it's attempting to do in a short period of time, or extend it with confidence, in the tests/implementation, that it wouldn't break, it's not the solution to the problem.
This is the hastiest of hasty abstractions. Please never write code like this for the frontend. It's fun to see, but it's definitely not realistic or production worthy.
If this comes off as mean spirited, i promise that's not my intent, i'm trying to approach this in good faith.