Hacker News Reader

Comment by ascotan | Hacker News Reader

This all started with angular imho. There was a time when structure, layout and logic were more cleanly separated. Angular blew this up with <ng-xxx> tags (which was a step backwards towards PHP imho) and this has been driven forward by other frameworks since. It surprising to me how so many people can talk about shadow dom but can't name any of the HTML5 apis or even more than a few tags and what they do (much less anything about CSS3).

View on HN

> There was a time when structure, layout and logic were more cleanly separated.

Yes, and what many developers started to realize is that this separation is not very useful (at least for proper web applications, as opposed to websites with mostly static content). Conversely, separating the building blocks of application into components where structure, layout and logic commingle is very useful.

I realize not all developers agree with eschewing structure/styling/logic separation. But many do and it's important to realize that they do so consciously and not because they don't know what they're doing.

Angular was one of the first (perhaps the first, not sure) libraries to move towards this direction. It brought a lot of accidental complexity with it, which is understandable as these concepts were only starting to be fleshed out in the web world.

It was React. React made it so that you could outsource your markup to libraries, and the community adopted the mindset enthusiastically. Along with that was a focus on composability over what actually gets produced.

React has always been about making an abstraction layer of its own; to remove focus away from the underlying platform. A metaplatform, if you will. That explains the problems described in this article, it explains the desire for CSS-in-JS (which despite arguments for, is only popular in React and no where else).

So what we've wound up with is a generation of developers who are really good at the lego-block building aspects that React provide (which are valuable) but know next to nothing about HTML or CSS.

I don't really think React is old enough to say developers know next to nothing about HTML/CSS.

CSS-in-JS still requires knowledge of CSS, albeit a subset usually. The same could be said for JSX and HTML.

If you can work with React you can work with raw HTML/CSS. It's just you have all the problems that come with those that maybe some developers haven't had the misfortune to deal with.

The React workflow gives you a right sense of direction, where usually you'd be left on your own.

It sounds like you agree with me. Yes, you have to know some things. Developers who came in in this culture know that inputs are for typing things and that divs are for block level elements and span for inline ones. That's a far cry from knowing HTML.

There are many developers who don't really know anything about the head element because its something their tools generate and they don't touch.

Yeah I didn't really know where I ended up once I finished the response. I suppose I partly agree with you. If the developer was able to learn the React ecosystem, they'll be able to learn the more advanced parts of dealing with a pure HTML/CSS project if they need to. I think the form of a middle-out approach to learning is better than working from "fundamentals" you may not even need. There's so much to learn in the web ecosystem, a lot of it being optional. I think starting with React and working backwards and forwards is a just-fine strategy.

One of my interview questions is "how do you organize logic and state in a react app?" and about 19/20 candidates put their business logic in their view components. I believe the root of the problem is the ecosystem of terrible react tutorials that are targeted at beginners so can't introduce complex architecture. If you spend some time reading react blogs you'll see that almost all of them put their API requests and business logic inside component lifecycle methods. The flood of bootcamp grads has made hiring competent front end devs nearly impossible (not to slander bootcamp grads; I've met a few that are brilliant).

>you'll see that almost all of them put their API requests and business logic inside component lifecycle methods

Edit: (I rephrased this post) I understand that logic often makes sense to break out between presentational and container components, and I understand that sometimes api / service calls should be broken out into their own files, but everything I've read states that api logic should be called from ComponentDidMount.... you are saying that you shouldn't make api calls, from component lifecycle methods whatsoever?

I'm not sure what the alternative is?

Yes, sorry I should have been more specific. You always have to kick off the process from somewhere, so your lifecycle methods will call out to wherever you choose to keep your non-UI application logic. There are a million ways you could implement that, from a state management library or just good old OOP classes and methods. If your code is well structured, you should be able to swap out your component framework without having to refactor any of your business logic.

When I ask this question I'm just looking for any answer that displays some knowledge of separation of concerns. Surprisingly, so far only a few out of dozens of applicants have been able to do so. I should also point out that these applicants are not applying for junior positions and all have ~5 years of front-end experience on their resumes.

I'm also curious why my comment above has been attracting downvotes. Did I say something rude or controversial? (I'm not complaining, just curious)

The alternative is side-effects. Pick your poison, redux-sagas, redux-thunk, etc.

I prefer redux-sagas because generators fit the bill perfectly, and they test easy, and I'm not a huge fan of Observables.

The components dispatch an action, and the heavy-lifting is done by the side-effects library that listens for that action, and does any API calls, as well as dispatching any more actions.

I would also love to see resources that detail how to separate business logic from view components. As a junior dev, I know it's the right thing to do but I'm not sure how. Is it as simple as passing props into a utils file?

Any links would be greatly appreciated.

https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

So I'm aware of the difference between presentation and compositional components, but the original poster was claiming service calls shouldn't be in lifecycle methods? Abramov puts his api calls into ComponentDidMount in his egghead.io videos...

That doesn't scale after awhile. Generally the next step is putting your business logic in HOCs or Redux thunks or sagas. Now it can be dropped in hooks too.

Use container for the business logic and the component itself just for the view logic. So for example you would have <ToDoContainer /> for the business logic and <ToDoComponent /> for the view logic. Do i get the job? :P

That's just as shit. You need to build an API layer and a service/utility layer. These should be completely separated from React-land. Ideally you should be able to change UI frameworks without altering or moving any of your business logic.

>Ideally you should be able to change UI frameworks without altering or moving any of your business logic.

That's just as shit imo, adding unnecessary complexity for the sake of adding it. If you are choosing a framework, you are betting on it, why complicate things. Might as well write in Vanilla JS at that point.

It adds easier testability - you can test the logic outside of the framework.

Reply on news.ycombinator.com