The biggest problem I have with React is that it’s not reactive.
And the biggest problem I have with hooks is that they make functional components non-functional.
This is starting to look like a pattern… :)
React I love you, but you're bringing me down
531–540 of 574 posts
Re: React I love you, but you're bringing me down
#532Earlier quoted context omitted.
Yes I've also seen a bunch of these apps with extremely chatty graphql calls because it's so convenient! One component just needs 2 pieces of data = graphql call. Another needs more data and they're doing another similar call. And so on. You got query flexibility but now you are drowning in additional network requests because it's so easy for your team to just "query for what they want". To me, if your application do…
Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component. This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M
That doesn't prevent your frontend and components from making a ton of extra network requests because graphql makes it easy for frontend devs to do fire a new query for their component.
Simple example:
1. header component - dev queries user for first name to do a welcome message.
2. sidebar component - another dev does a query for first/last/avatar/profile/etc.
Your app sends 2 network calls. Certainly it doesn't have to, but I've seen this chattiness get implemented.
So you avoided overfetching of data like official REST APIs but now you have more network calls.
Re: React I love you, but you're bringing me down
#533As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…
I just use vanilla JS on the front-end just like I do with Node. I have never understood why people find state management challenging. I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my state data in one object, save it on each user interaction, and…
> and use it only on page refresh
Doesn't that mean you can never reflect state updates in the DOM without refreshing the whole page?
> I have never understood why people find state management challenging
Automatically determining what DOM objects need to be updated in response to a change in state and updating them without a page refresh adds a lot of complexity, if you completely ignore that requirement then state management would be simple like you said.
Re: React I love you, but you're bringing me down
#534Earlier quoted context omitted.
Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component. This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M
That doesn't prevent your frontend and components from making a ton of extra network requests because graphql makes it easy for frontend devs to do fire a new query for their component. Simple example: 1. header component - dev queries user for first name to do a welcome message. 2. sidebar component - another dev does a query for first/last/avatar/profile/etc. Your app sends 2 network calls. Certainly it doesn't hav…
Yes, it does. As I explained, GraphQL servers can see which requests should be collated and deduplicated and puts them all into one request. For example, Relay:
> Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determines statically (i.e. before your application runs; at the time you write your code) the requirements for an entire view!
> This is achieved with the help of GraphQL. Functional components use one or more GraphQL fragments to describe their data requirements. These fragments are then nested within other fragments, and ultimately within queries. And when such a query is fetched, Relay will make a single network request for it and all of its nested fragments. In other words, the Relay runtime is then able to make a single network request for all of the data required by a view!
https://relay.dev/docs/principles-and-architecture/thinking-...
Re: React I love you, but you're bringing me down
#535I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…
> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…
I primarily agree with you, but his primary point is mainly regarding the tendency for projects at large organizations to have a substantial number of unfished attempts to rework existing applications, which often results in serious headaches for whoever owns the code.
What I mean is that even if you've followed a specific set of programming principals, code practices and design patterns consistently across the life time of the application, there will still have been initiatives to change how things are done. Maybe they want to use a "better" authentication library, or add a material framework that has capabilities they need. The exact initiative, and how valid the request or decision is doesn't matter. These initiatives may occur one at a time, or be competing with each other for priority while being incompatible without anyone noticing. But some of them will fail to be completed, and someone has to back out the changes that shouldn't go to prod. Inevitably something will get left behind. Over 5-10 years this can have a shockingly large impact on the code base in ways engineers frequently notice but don't understand how the code got to the state its in.
This frequently means dead code, unused dependencies, comments that don't make any sense, properties on objects that are never displayed or referenced by business logic, and multiple classes/services which accept the same inputs and produce the same outputs but do the job just differently enough you can't be sure it's the same. That, and over abstractions (any piece of code which branches based on the context of "who's asking").
And frankly few things any me more than someone who felt the need to implement their own logging implementation, especially in C# (yes I know we're talking about React, but people do the same stupid crap in that case as well). Reinventing the wheel has to be done on occasion, but you need to ask yourself if it has to be you that makes it happen,and whether it already has been.
Re: React I love you, but you're bringing me down
#536Earlier quoted context omitted.
Yeah I'm not entirely sold on GraphQL but I think it shines in some cases. Ex: you are building on top of third party ecommerce software. You need to add more data to the Cart entity because you have a custom module/plugin/etc. You write a graphql resolver, extend the schema and the Cart type. You can use the existing built-in endpoint to query your new data. So it's nice to be able to extend a framework and data acc…
Parent is mixing up GraphQL and ORMs which serve two completely different purposes and doesn't seem to have actually used GraphQL. GraphQL is purely a way for a client to request some data instead of REST. How the backend serves that request is not any concern to the frontend, the backend can use an ORM or it can use raw SQL, or whatever else it wants.
Yes I think you are right; I wasn't following the ORM part either. I mean, you can return whatever you want so long as matches the schema. Hard code it, raw sql, whatever.
I wrote some custom resolvers yesterday to extend graphql on a Cart entity and it works well for that.
I used some existing repositories the backend already had but was not yet available on the GraphQL side.
All the resolvers can lead to extra performance issues of course, but I suppose you can adjust your schema as needed and tune it with more efficient queries or code (ex: move some properties to nested and resolve with a single tuned query)
Re: React I love you, but you're bringing me down
#537Earlier quoted context omitted.
That doesn't prevent your frontend and components from making a ton of extra network requests because graphql makes it easy for frontend devs to do fire a new query for their component. Simple example: 1. header component - dev queries user for first name to do a welcome message. 2. sidebar component - another dev does a query for first/last/avatar/profile/etc. Your app sends 2 network calls. Certainly it doesn't hav…
Yes, it does. As I explained, GraphQL servers can see which requests should be collated and deduplicated and puts them all into one request. For example, Relay: > Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determin…
Ok but I'm talking about your client application sending multiple network calls at different times. How does the server prevent that? It doesn't.
In order to prevent the frontend from doing that, I have to be sure to enforce usage of another layer. Devs need to use fragments and relay and not just fire off their own ad-hoc graphql queries.
Which is interesting, and thanks for sharing. I would move toward implementing this on any graphql project, especially an inherited, network chatty graphql project.
But I still prefer keeping the frontend really dumb and just sending the data it needs, that has been identified.
Most of the time a REST or REST like API endpoint is sufficient, and it doesn't matter if you overfetch some data, you avoid extra graphql layers (now enforcing fragments/relay, extra resolvers, potential performance issues, multiple schemas and access concerns).
I like GraphQL but it seems like a lot of overhead for little gain for many projects. One project has 3 different graphql schemas. Can't be exposing the whole tree to every user type.
I can see why frontend devs would like it though (need this data, probably already available), but a REST or REST-like API is more enjoyable for me unless I'm building a framework or on top of a framework or a client that needs ultimate ad-hoc query ability where it really shines to me.
Re: React I love you, but you're bringing me down
#538Earlier quoted context omitted.
That's why I like GraphQL, you get exactly the data you request, no transformation necessary.
Graphql does not address the problem he's describing. When he says "transformation" his meaning is similar to transformation in an ETL process. What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be. This is very dangerous behavior for any application. You don't…
> What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be.
But you don't have to do it like this at all. I don't understand what this has to do with GraphQL, you can make the frontend never update local state and only fetch from the server if you want. That's an implementation detail not related to GraphQL, REST, or any other API format.
> No matter how you try to look at it, spreading business logic out across your applications various layers always has unintended consequences for maintainability and even scalability.
I agree with you here, but for:
> In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway.
Again an implementation detail, if you're the tech lead, just tell your devs (or architect the app in such a way as to) not to put business logic into the frontend.
Re: React I love you, but you're bringing me down
#539Earlier quoted context omitted.
Yes, it does. As I explained, GraphQL servers can see which requests should be collated and deduplicated and puts them all into one request. For example, Relay: > Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determin…
Ok but I'm talking about your client application sending multiple network calls at different times. How does the server prevent that? It doesn't. In order to prevent the frontend from doing that, I have to be sure to enforce usage of another layer. Devs need to use fragments and relay and not just fire off their own ad-hoc graphql queries. Which is interesting, and thanks for sharing. I would move toward implementing…
By that logic even a REST endpoint server can't stop people from making network calls at different times. How would you even stop that, simply make people wait until a set time before collating and sending out the data?
Re: React I love you, but you're bringing me down
#540Earlier quoted context omitted.
Ok but I'm talking about your client application sending multiple network calls at different times. How does the server prevent that? It doesn't. In order to prevent the frontend from doing that, I have to be sure to enforce usage of another layer. Devs need to use fragments and relay and not just fire off their own ad-hoc graphql queries. Which is interesting, and thanks for sharing. I would move toward implementing…
By that logic even a REST endpoint server can't stop people from making network calls at different times. How would you even stop that, simply make people wait until a set time before collating and sending out the data?
I don't see frontends using REST servers doing what I see with GraphQL.
UI using REST server tends to centralize the API client, call the endpoint(s), and make that available to all components.
UI using GraphQL often has frontend devs doing their components, running their ad-hoc queries for "just what they need". More network calls.
So overfetching like with REST tends to lead to less network calls unless you are extra diligent on a GraphQL project.