3 ms·

I prefer it when render functions are pure and just render. Given some input, produce html that can dispatch some messages. Deal with the state somewhere else.

I prefer it when render functions are pure and just render. Given some input, produce html that can dispatch some messages. Deal with the state somewhere else. I don't want to have to reason about when a component mounts, how many ways it could trigger things, that will cause itself to render again and trigger more unexpected things. Why did a component mount? Maybe the route changed, well I will just fetch data where I handle that event. Maybe I got an API response, well guess what I can do stuff right there. All I had to do was let go of the idea of "component". I know, we need to make layers, and isolate modules, separation of concerns. But "components" are unsatisfactory for me, because all I ever got was implicit dependencies. Sure this component deals with his own data, and its children do the same, but somewhere, they DO have to talk to each other at same point, always. The component depends on the user, or user's list of thingies, and bam I've smeared it all across all of them. Because I'm building an application, not a component catalog. Also testing is a PITA. I think most of the time it's useless to test a component without the whole app, and then it's an integration test, but you really want an e2e test by then.

erikpukinskis 7y ago
> I think most of the time it's useless to test a component without the whole app, and then it's an integration test, but you really want an e2e test by then. I tend to agree. With a couple of caveats: On my team we have visual tests that use factory data to just make sure different states of each widget look right. I think it’s pretty valuable as a safety net for CSS refactors. We use Chromatic for this, but they charge per state, so even a medium sized app will get into the $500+ range per month. I also think that, while in practice every front end I’ve worked on is tightly coupled to the backend (making front-end only testing pretty useless), if you build an “optimistic UI”, you can do it. We got close to this at my last company, where we used Vuex to implement a kind of a simple dB on the client, and allow server syncs to kind of build up in the background as needed. You still need to stub some initial requests, but you could test a UI by doing that and then kind of “coasting” in the front end. Eventually you’d hit an interaction that needed the server, but in this way you can test some short sequences of interaction, which is probably enough to test the basic interactions, and leave the E2E tests for actually making sure the front end is wired to the server, db, work queues, etc correctly.

erikpukinskis 7y ago

> I think most of the time it's useless to test a component without the whole app, and then it's an integration test, but you really want an e2e test by then. I tend to agree. With a couple of caveats: On my team we have visual tests that use factory data to just make sure different states of each widget look right. I think it’s pretty valuable as a safety net for CSS refactors. We use Chromatic for this, but they charge per state, so even a medium sized app will get into the $500+ range per month. I also think that, while in practice every front end I’ve worked on is tightly coupled to the backend (making front-end only testing pretty useless), if you build an “optimistic UI”, you can do it. We got close to this at my last company, where we used Vuex to implement a kind of a simple dB on the client, and allow server syncs to kind of build up in the background as needed. You still need to stub some initial requests, but you could test a UI by doing that and then kind of “coasting” in the front end. Eventually you’d hit an interaction that needed the server, but in this way you can test some short sequences of interaction, which is probably enough to test the basic interactions, and leave the E2E tests for actually making sure the front end is wired to the server, db, work queues, etc correctly.