Skip to content

re: The biggest mistake library and framework maintainers make VIEW POST

re: @uniwrighte - Definitely not looking at Angular as a good idea, though I do appreciate the slightly more structured code in something like Vue ver...

With great power comes great responsibility I guess.

For me spagehtti code is when you consistently have to open 4 or 5 files to understand what is happening.

As an experienced React developer, I can read almost an code with accurately named components within a few minutes, and I usually can understand the strucure w/o opening more than one file.

Your App.js is the entry point, whatever you name it. Find that, and you know what the entire application does, unless someone intentionally made it harder for themselves. I don't have much experience with Angular, so I won't really try to compare, but I do know that other devs complain about sifting through boiler plate. With that said, I'm also sure there are some poorly designed Angular implementations out there.

As far as react-router-dom, the reason you would want XML for your routes is to make it more declarative with your components. Instead of reaching around to some function and tossing your components into it, you can just declare it directly.

If you wanted to do it out of JSX, then here:

const routes = [{comp: Comp, path: "/comp"})

and a one liner in render OR you could make a stateless functional component:

{><Route path={route.path} component={route.comp}/>)}

You can do it however you want, but the point is that it allows you to interact with the DOM via a logical abstraction instead of boxing you into a do-this do-that model like jQuery or possibly almost any framework with a rigid structure. If you think about it VanillaJS/jQuery are about is strict as it gets, because you have to declare every action (or try to work around that and build your own version of a view library).

P.S. don't know how the code will look on this platform, so thank you for bearing with me

code of conduct - report abuse