Experimenting with a react MVC concept (don't do this) 

The one person in the comments who actually understands real life issues with react doing the defacto approach. Thanks for the comment, it gives me hope that other developers understand the complexity react often brings in large projects

@@WebDevCody Any plans to make this code available? Would love to play around with it

Totally! Experienced with creating our Saas Platform and not doing TDD was a hell experience for us.Test cases gives a good documentation

Absolutely agree. I'd say most negative comments will be from the context of relatively simple projects. Large and complex enterprise solutions are much easier to maintain leveraging abstraction patterns like this.

@@andrewl2891 added the link to the description

Well, all this is pretty subjective. But the main point you need to focus on is the fact that he is detaching (or trying to detach) the behaviour of the component from the interface itself. Nothing else. There's no special state machine nor patterns here to understand aside from the fact that the component behaviour is being separated for it's interface markup. In my personal opinion tho, apart from the fact that you can indeed do unit testing with ease in this approach. I think this will lose it's value in more complex applications and it falls a little under the overthinking umbrella. But surely a thing that every developer out there has faced, the inherit convuluted stance on React components.

@@joaomendoncayt I agree, you never know if an approach is good until you use it to build a large scale app

@@WebDevCody for sure! I mainly do frontend and work a lot on the blockchain industry, and I've seen things I can't unsee 😅 when wallet adapters were in their really primordial phases for example... A team of like 5 - 10 people contributing to a single huge component as simple as connecting your wallet, full of hooks states derived states and so on... It gets insane to write a new line of code inside such projects... And it's pretty cool that you are trying to encapsulate that outside of the component. I'd have to try it out because you will still have to leave a couple logic on the component itself and might get akward but it's a big problem with react that needs attention for sure

Yeah the proxy thing is my own little custom hook that wraps the react state as a proxy object. The code is in the description

Because I’m not trying to solve the global app state problem. I’m solving complex component state and logic. Two different problem spaces

@@WebDevCody have you looked at any of the state machine libs in the react space?

@@WebDevCody logic and state are real issue with big apps but when to make components, when to make a controller and how much should we put in a one plate for the Code like this . Just curious about that

@@WebDevCody I appreciate that, and It's something that I'm trying to solve in my own projects. The first thing that worked was redux + redux-thunk. It's definitely a lot of boilerplate but it did mean that I can set up all my setters in the action creators and I could use mapStateToProps to sort of work like a getter. It was a lot of boilerplate, but I did extract all of my logic out of my components and things just worked, which was nice. I then tried useReducer and useContext to create a similar workflow minus the boilerplate and the redux. That also worked, and it did allow me to have less boilerplate (though there was still a small amount). I'll check out your approach on a side project and give you some more substantiated thoughts.

But the real question is, how often you will want to do that? It's just useless abstraction for 98% of projects.

@@sanjarmirakhmedov8311 depends really. Some companies do that often with different products. Like IaaS and PaaS companies.

It’s not a unless abstraction if the unit tests become a lot easier to implement and manage. Separating logic from views is a legit thing many developers much more experience than most react devs, such as uncle bob, Martin Fowler, actually know what they’re talking about

I can see it being useful for design system components to be able use those controllers to create components for mutiple frameworks

@@sanjarmirakhmedov8311 I joined a company awhile back and had to rewrite their whole application from bottom up . Maybe if I took an approach like this, say in 4 years we want to rewrite it, then it's more plugin and play. I get what your saying thought but this is a good design approach.

same thing can be said about the entire web dev industry, salaries are lower because of the tech bubble that's dying (look at netflix and facebook stocks) + youtube taught everyone how to code + you can't compete with devs from india and pakistan ect... they'll do everything that you can do for 1/100 of your price.

@@timalk2097 that's true

@@timalk2097 Well, everything but build a small, efficient, maintainable system, that is. 😉 I haven’t had great luck with offshore developers, to be honest. I usually end up having to pair them up with senior local developers anyway. Otherwise, I just get an endless supply of emails asking me if I can figure out why their code isn’t working properly.

Good suggestion

You could useSelector at the top of your component and pass it into the controller as an argument. That allows us to easily mock the zustand call to verify my component successfully updates the zustand store when certain events occur. You can still have the controller be passed a dispatch function and invoke dispatch from your controller if you want. Dispatch is just a function and isn’t react specific.

That's because it's the wrong framework to use like that. React is not meant for this.

@@christianferrario could u elaborate on that? what would you do instead or which framework you'd use

@@christianferrario I also would like to know why React isn't meant for this and what would you do instead?

@@fonzanedelungini the FLUX architecture

Glad you see the benefits, not many others will

I would love if you take it as a seperate series. thanks in advance for sharing this

Yup I love dependency inversion / injection. It really makes testing easy

No, it’s just pulling out component logic from the component. You’d still need context or state lifting when two components share state

yeah, I feel my approach is very close to MobX, but with my own little tweaks that make it fit my preferred way to mutate state. I could see how MobX could be very useful in achieving same thing I'm doing. Obviously my approach doesn't try to tackle the "global state" problem. This approach is just tackling "how to get testable logic out of react components". One can still use context, zustand, prop drilling, mobx for managing higher level state, all this controller function cares about is send me the dependencies I care about and I'll return methods you can use for modifying those.

Using Global State for everything is also a bit of an overkill, you should better aim for local react state as much as possible, and the global state manager ideally should be your last resort. React Local State + Server/Client Sync Library Like react-query/apollo-client + React Context for trivial global state should be sufficient in 90% of the times.

I haven’t thought much about this after making it

Redux sucks, but yes you can always use a popular state management library if they check off all the boxes you’re looking for. My check boxes are just a bit different

@@WebDevCody Could you explain why, please? I've never used Redux so far but would like to know why people think it sucks.

@@BroadcastYoToBe Modern redux with redux toolkit seems totally fine to me. The boilerplate is cut so much with toolkit. Not really sure where the bad rep is coming from.

@@Krzysiekoy toolkit is also convoluted. useSlice and createAsyncThunk, extra boiler plate related to reducers in general, builder.addCase. This is the opposite of simplistic

@@WebDevCody Maybe you should take a look at your "MVC" before saying something like Redux "sucks", especially when your channel is about educating people. This is a bad influence on newbies, Even tho "redux sucks" for you, show me a job opening that doesn't ask redux or similiar state management.

Angular isn’t bad anyway. Vue does a similar approach, and svelte has a similar state management. React is the odd man out when it comes to state and forcing immutable state changes

In description

I’ll have to learn more about vue. It was a pleasant experience when I used vue 2 a long time ago. You should join my discord. You are knowledgeable and there are a lot of people who might need help with vue or just coding in general. Thanks for this response, this is all good info for sure. I like how vue can easily be tested without coupling directly to react.

But I don't unit test so on the other token I like having everything (ui and logic) in the same component in question.

I disagree, I think this is fine, and being able to properly unit test your logic is necessary. RTL is an integration testing library and you have to accept the philosophy that all tests should only test at the dom level which is incorrect imo. Your model would always be an object which you’d have properties with any primitives you needed. There isn’t any performance benefit to having 10 separate useState calls, react still rerendering the entire component when any state changes. There is nothing wrong with the proxy unless you can prove it actually causes any type of noticeable slowdown. Another real world benefit, I can take this controller and throw it into any other front end JavaScript library and it will work the same as long as I just bind my components correct. That’s when you know you have true separation of concerns.

what test ensures you bind the controller logic to the components correctly?

you need a vacation He was clear in the first minute that he has a few things he works on where his code is getting unmanageable. For his specific situation, he needs things to be simpler through a little bit of complex engineering. Although i wouldn't make a proxy just for one component, not even if i were playing with code but i have done it in a few places where there was duplication of controll logic and it just made sense. Testing is important based on specific problems and use cases, ask the people who decided to not fully test the sls rocket. But dont write a whole unit test for a hello world test Some test are meant for validation while others are for future guard rails that hopefully point out where you deviated from business goal while making changes.

@@WebDevCody 1. Doesn't @testing-library/react-hooks solve the issue of testing the logic in isolation from the DOM? 2. Regarding the model object I have not mentioned that it can hurt performance, I meant what If I want to create a simple primitive value state without the need to create that proxy state. As I understand with this approach you are forced to use that custom proxy state, because as you are stating, you want your logic to be isolated from "React" and be testable "Without RTL" which is kinda absurd, if you look into it this way, you better abstract literally everything that you have in your app with your own layer which of course is absurd and useless in real world projects. I would rather do a full rewrite if it will ever happen in theoretical future than trying to use abstractions like these which creates unnecessary complexity and brings this weird proxy based state updates, plus you have to correctly bind all this logic into the framework, and I'm sure it won't be easy to bind it to different frameworks, you will still end-up with some hacks/workarounds that will make your and your colleagues life harder.

You can do it the same with next js, thing is if you want to do it like guy on video just switch to angular.. way easier.

Angular is a complete different ecosystem. So no, switching to angular isn’t the same as rethinking a basic way to separate business logic from react components

I think also splitting things up into smaller components causes more indirection and complexity. For example, how would we split up this modal? Would we have a SelectAll component? Then individual ToppingOptions component? You end up pulling state up anyway since they all need to read and modify a shared state. I don’t think there is as much indirection with this approach as you think, I have a separate function above the component, that’s it. It’s the same indirection if I pulled out custom hooks and defined all the functions there. My main goal is to keep useEffect and other react primitive hooks out of my logic. But yeah, I’ll check out your state library, it sounds cool. I also like zustand and I’ve used it on a side project, but I don’t think it’s the same problem I’m trying to solve using dependency injection to decouple my controller from the outside world

I’m not too sure I follow because I did exactly that in this video. I separated the logic from the view. You’ll still always need some type of hook, but you can just use dependency injection to send those third party hooks to your controller which allows easier mocking under test and easier tdd

@@WebDevCody with react, things just get over complicated and messy and with hooks event worst, even you create a custom hook, just try solidjs that you will not need even to create a custom hook.

​ @Web Dev Junkie It would be pretty cool if you made a tutorial like thing where you explained how you make this kind of proxy-controller setup. Maybe it would inspire a new style of client side react.

I always called redux the prime example of over engineering, even toolkit has tons of boilerplate. Yes redux is a tool for separating logic from views, but it’s a global store. I’m trying to solve the issue of complex component logic and state changes and make it also easy to do TDD

@@WebDevCody I am definitely not saying that we should go back to redux. But a simple HOC would go a long way.

@@asdqwe4427 useReducer hook

@@devthagichu yes, for sure. But is someone really wants to test the component separately from the state, then you could have your useReducer, useContext and all of that in a hoc. Then you’d export the component separately and test it separately.

Yeah useController was a bad name for it. It’s more of a factory function which I should have called makeController. The idea wasn’t to make it generic. It’s a very specific controller used to control this view. I don’t recall useProxyState having any custom logic, it’s a generic way to wrap an initial state variable.

@@WebDevCody useProxyState has the setCount which receives the cb function for updating the state which is specified inside useProxyState rather than passed inside it. This is the custom logic that I was talking about. The general idea as I understood is to make our components smaller, testable and more readable

@@MascleGinger ah ok, there might be a better way to not need to do this counter state update hack. Maybe I can just use a memo and pass that as initial state for the useState hook

Yeah I like vue, but also like the functional approach to react.

I’m not a fan of immutable code, And I find reducer forces me to use immutable code with additional boiler place causing bad dx and harder to read code, but that’s just my opinion. What is react like react code? Does that mean using context? Using redux? Using custom hooks? Using class components? React is just a view engine, let’s treat it as such imo.

​@@WebDevCody I get you as for dx in regards to hooks more so useReducer hook, the documentation is quite clear and for redux, we can say we have come a long way... there are better docs now that address Dx, for boilerplate code, your MVC solution also comes with some boilerplate, I am keeping an eye though on your idea tho 🙂

I think in that instance we can still use zustand or context and share state between components. But we’d pull in the zustand state and pass that via dependency injection to our controllers as needed. There is also nothing preventing us from defining multiple controllers in a same view I guess. Like with all things, break the convention if it’s not working for the feature needed. Let me think on this more because I only half understand your concern. 🍻

​@@WebDevCody My concern comes from sharing logic rather than data. A model is usually more than just a dumb class for data, meaning it encapsulates its behavior. So the problems I see vaguely: You have a model that needs to be used in X amount of components now you either - duplicate that model - use the same model the first one should be obvious what kind of troubles this might bring, so let's focus on the latter: - You are now giving any component the ability to mutate the state of that model (assuming we have behavior there cannot be invariants but still) - Your model might become massive, maybe you need 2 props for just that component but the model itself has like 20. - You have an iterable inside that model which is empty for that component because you don't include it in your fetch, some kind of invariant..? This is why I like MVVM because the view model knows about the model and exposes only the things that the view needs but the view does not know about the model, only the view model.

For sure, I think all of these frameworks have their prod and cons, and I do like the mutable approach to svelte, vue, angular. There is a ton of cognitive load around setState since it’s an async function, sometimes you need to pass a callback, it’s not intuitive and a majority of the noobies get tripped up on this fact. This is still just a prototype approach so it might end up being terrible, but I’m slowly trying to tweak it to meet my needs and figure out of this is truly a benefit or a waste of time lol

How do you suggest I use custom hooks in this scenario? What would each custom hook actually do? What logic would it contain. So instead of centralized logic for this component, split the logic it into multiple hooks? Not saying you’re wrong, I just need a concrete example to grasp your suggestion

@@WebDevCody ​I think if you’re trying to strictly stick to an MVC approach it’s good but personally, I’d just have a useToggleList hook that’d own the state and fetch the data on load. Then I’d just return the state and the methods so that they can be accessed. I think this would better achieve the purpose of abstracting logic away from the component while allowing for the same logic to be reuse elsewhere in the project. It’d also mean that only one hook is needed rather than useProxy aswell. I think there’s just some unnecessary complexity that’s been added which is what I try to avoid! Looking more into it though, it doesn’t seem too bad. Being new to this way of doing things would be a factor for seeing it as being overly complex too no doubt.

Just use typescript if you want types, and how do you build a front end with java? You’ll need JavaScript right?

I don’t have a problem with react, I still think it’s the most flexible framework with the best ecosystem. My gripe is with state management and overly complex components hard to unit test the logic behind

Both unit and integration testing are important. Unit Tests are usually only brittle if you wrote them poorly. In this example, I can unit test the modal, unit test the container if needed, and write a single integration test between the container and the modal to verify the modal is populated with the proper selected toppings because that’s the one point of contact those component have with each other, maybe verify a single modal save sends back values to the container, but if you have good unit tests, you can trust the integration will work fine

@@WebDevCody Brittle tests usually test things which we don’t actually care about. E.g Example from your mvc toppings test “Does initial view show correct selected toppings” Test 1: RTL - findbylabel, is cheese checkbox selected is pepperoni checkbox selected Vs Test 2: Controller Unit- Is selected topping in this shape and equal {“cheese”: true, “pepperoni”: true …} Now a new requirement comes in where I have to change the shape of selected topping to store other info: { “cheese”: { selected: true, info: “this is not vegan”}, “pepperoni”: { selected: true, info: “this is spicy”}} Given implementation is correct: Test 1 RTL will pass will pass with No updates Test 2 Controller Unit - will Fail if not updated - Now I have to update this test every change , Brittle… where is value add here?

@@ukman1234g what’s stopping us from calling a getter call isAllSelected and expect it to be true? I agree that the test shouldn’t check the model directly if possible since that will result in brittle tests, and you’re right this test in the video might be brittle if I change the structure of toppings. In my defense this was a prototype with some basic tests I didn’t think hard about

In description now

@@WebDevCody Thankyou Teacher

K, makeController?

@@WebDevCody It technically gets the controller so we can say getController.

Wouldn’t hurt to just try and see if it helps any

Not sure your argument. The reason we have these frameworks is because manipulation of the dom is unmanageable with complex business requirements. We moved away from jqueuy and vanilla js because of complexity it brings on larger applications, so now we use vue react svelte angular so that we don’t need to think about how the dom is updated.

@@WebDevCody Don’t mind me. I’m from a different era. I just want to suggest that you can choose how complicated to make your own lives, usually. If you are working within a web browser, you get JavaScript and the DOM for free. Everything else is optional, and anything you decide to add to it should probably add more benefit than cost. If it doesn’t, then you may want to consider not doing it in the future.

@@AftercastGames No offense (not really), but you clearly have no idea what you're talking about. Not introducing complexity into Web applications is not a novel concept by any means. Much smarter people than you have considered this already. The modern state of Web development is to bring an experience as good as, if not better than, native applications on an OS to the end user. Expect we don't have the luxury of our apps working in an OS. The applications we create have to work in a browser. And we have to code it all out in javascript. The complexity isn't something people are just throwing in for fun. Building something as basic as an empty Facebook clone would be hell without a framework. The problems are complex, hence why the solutions are too. You also don't need to tell us that you're from a different era. Anyone who glances at your comment can smell the reek of boomer from a mile away. Do us all a favour and shut up. I've got a feeling that between the geniuses responsible for building these frameworks in the first place in response to a need, and you, some random old fart, that you're the one that needs to stop your madness and stick to your lane.

@@AftercastGames You have no idea what you are talking about. Sure for a simple portfolio site or blog page I would not recommend a web framework. However building a web application without a web framework is hell (I've done it before). The reason why we have web frameworks is because for web applications the dom is constantly changing and being updated and having a web framework keeps tracks of what components to actually update instead of entire web page refreshes. This is one simple reason I can think of on the top of my head without going into state management.

“The complexity isn't something people are just throwing in for fun. Building something as basic as an empty Facebook clone would be hell without a framework. The problems are complex, hence why the solutions are too.” This is precisely my point. “Facebook” isn’t a complex problem to solve. People post messages, and other people can see those messages. And 75% of that work is done on countless servers, not on the web browser. That just leaves things like formatting, editing and displaying messages, images, links and videos. Most of this is handled by the browser itself. There was a time when the web browsers had different behaviors and different functionality, but those problems have been largely resolved. Chrome is now the lowest common denominator, in terms of functionality, and modern UI designs are so flat and monochromatic that you might as well be using a black and white monitor from 1979. The web development industry is a joke. You literally have the simplest job in all of software engineering, and you’ve managed to over complicate it beyond recognition. The solution to a complex problem is breaking it up into multiple simple problems. The solution is not to invent your own complex system to hide the other complex system. It’s your choice. Throw as many libraries and tools in as you can, and then when it gets to be too much to deal with, just quit and find another job. That’s what most people do these days. The rest of us will clean up the mess that you leave behind. The system that I’m currently maintaining and adding new features to has over 18 different UI technologies the last time I counted. Every 3 months, a new UI library is introduced, and naive developers happily add it to their existing and new projects before realizing that there are unexpected issues and complexities with this new technology, just like all the rest, and start looking for a better solution. Whenever you guys settle on one set of tools for more than 6 months, then I will consider giving it a try. Until then, I’ll focus on actual business requirements and functionality that makes people more productive. It’s easy to waste time and money playing with new tools every 3 months as long as someone is willing to pay for it all. And as long as the money doesn’t run out, of course. Good luck in your career. I wouldn’t be so quick to dismiss (or push back against) people with a lot more experience that are trying to give you some helpful advice.

That’s fine, this is just me doing some thought experimenting anyway

It’s just a function that returns methods and getters. This isn’t that complex

Yeah this is usually in the context of side projects. On a production app I use existing libraries when possible. It still doesn’t mean the current industry approach to react component is any good imo.

It’s fun to overengineer right?

Kind of, without the class and this keyword

Tailwind is fine, I thought the same way until I used it. I was a big sass css fanboy until I started using tailwind

No not really

@@WebDevCody so you can use vue if you want mvc model why implement react structure to something else bad readability in my opinion

Eh idk, if you have a third party dependency on your code and mocking that becomes problematic, restructuring your code to be more testable isn’t bad imo. It usually means you’ve probably isolated your app logic properly from the rest of your dependencies

This is not like redux. Go read the boilerplate involved with using redux and toolkit and compare it to this.

​@@WebDevCody You're right, it not like Redux. Redux Toolkit handles tons of stuff, besides separating the logic from the view. And you just created a function with a closure that returns an object with all the logic shoved inside. Do you know that there is a structure for creating objects with binded data? It's called "class". I guess it will be in the next version of your "new favorite way" to write code 😂

How would it lose portability? It’s a function that takes in arguments. Nothing or stopping me from having two or more controllers inside a single view with this approach right?

What exactly is a mess about it?

@@WebDevCody I have been programming around 30 years. Javascript is total scrap, all web development is not serious. Look at language like Scala that is 50 years in advanced compared to web languages. UI is not even close to what I had 25 years ago, pathetic.

Abstraction isn't a solved problem. Thanks for sharing ur research.

idk man, it is very weird indeed. I guess people hate when they are introduced to a new concept that goes against what they previously learned or might do currently in practice. Just because you learned it and do it daily doesn't mean it's the most efficient or easy to understand. Think outside the box, challenge thought leaders in this industry, think for yourself.

No clue what you mean