3 ms·
>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 th
by ep103 8y ago
>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?
- c0wboyc0ding 8y agoI 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.
- parthdesai 8y agohttps://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
- ep103 8y agoSo 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...
- phponpcp 8y agoThat 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.
- s_y_n_t_a_x 8y agoThe 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.
- deleted 8y ago[deleted]
- pault 8y agoYes, 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)