We have a business critical web app running on React, with a Redux state management and restful services. It's been in production for years now and is stable, but since then we have learned a lot and brought in new technologies.
NextJS 10
Routing
router.push('/status')
One other fancy and very useful thing is built in url param handling. So say you want to put a customer number in your url you could make a file /pages/customer/[customerId].js and when it is called like this http://localhost:3000/customer/8675309 then router.query will automatically have customerId=8675309 in it. No more need for custom servers. It's automatic!
Static Optimization
Styled Components
One thing we love is that careful naming can make your code much more readable.
<div className="header"><span className="label">Name</span><span className="value">Value</span></div>
Becomes this (ignore the blank space.... can't get it out of there):
<Header><Label>Name</Label><Value className="value">Value</Value></Header>
This becomes even more apparent on a busy page where you'd normally have 3 - 4 layers of nested divs, but instead in styled components each has a unique name like <Page>, <Detail>, <Summary> etc. so it's easy to tell where each part begins and ends.
You can also easily extend a styled component. So if I made a <GridValue> with 20 properties set and the text was centered and I wanted a <NumberGridValue> with a text align of right, you just extend <GridValue> and change the one property you need to change but inherit all the rest.
Another plus is that it uses all standard css. So if you are converting or have a designer who mocks pages for you you can copy/paste it into a styled component as is.
One final hurrah is that you can send properties into a styled component and make the rendering change based on the property.
color: ${props => props.isSelected ? red : blue};
Apollo GraphQL
We converted our REST endpoints to GraphQL queries and mutations. Many features led us to GQL with the built in yet simple typing, automatic input checking, automatic caching, local state support, simple client-side querying and very powerful hooks in React.
One really big advantage is being able to store local client state in GQL and the ability to query it out using the same syntax as the server side queries. So say the user makes a selection in one part of the app and we write it to local state. Everywhere else in the app that queries that same state will automatically be updated. Change your selected store in the store finder, and it automatically updates in the header!
GQL lets you query out only the fields you need. So say you're getting store detail, but in this case you only need the name to display. You can query just the name and not get the other 50 fields. Also if you've already queried all 50 fields (say for the store locator) your query for the store name doesn't have to hit the server again because GQL is smart enough to get it from cache. You can also run multiple queries at once. So when we get product attributes and product inventory (separate queries) we can run them both at once which reduces calls to the server.
Another major win was the ability to have local state drive the next query in a series of steps. So we used queries that were conditional on local state items, so they would skip the query until that item was set. So it happens like this:
- step1 value set => step 2 query runs automatically
- step2 value set => step 3 query runs automatically
We had a 6 step process and before we had large switch statements and tons of step handlers passed around to make sure all the steps happen at all the right times. Now it happens automatically by setting the state. No matter who sets the state, it will run or re-run if state changes. So click on the header and change a value..... query re-runs. Go through the wizard and change the value.... query re-runs.
For example this is one of our hooks and automatically gets product info and inventory once a siteNumber is chosen and a list of articles comes back from another query.
const {loading} = useQuery(GET_PRODUCT_ATTRIBUTES, {skip: !articles.length > 0 || !siteNumber,variables: {input: {site: siteNumber, articles},},onCompleted(data) {client.writeQuery({query: STATE_QUERY,data: {productAttributes: data.productAttributes,productInventory: data.productInventory,},});},onError(error) {client.writeQuery({query: STATE_QUERY,data: {error,},});},});
We also took advantage of our local state tree and save the errors there. So we have one component on our app that hovers over the page to show errors. Write null to the error in state and it goes away. Write the error on ANY query and it shows! We even re-used the same error component on our login page to show errors there without any extra coding.... just plopped it on the page.
React Hooks
We made extensive use of hooks to orchestrate complex operations and encapsulate a lot of business/query logic. So as you saw above, the query for product attributes was in a hook that was triggered when other state was set. The results get saved into state as well, so become available to any component by looking in the state. Have a problem with the product query? You only have to look in one place regardless of which component is showing the results...... product list, product comparison, product detail all use the same data written from the same hook.
If it was complex enough, we'd use one hook to orchestrate and call other hooks that did subtasks of the big task. We made each hook do one thing and do it well so the code was small, concise and easy to understand. Because all our data was in GQL local state, the hooks could trigger off that and no data had to be passed back and forth between hooks. So they were related, but not tightly coupled.
Conclusion
- has less lines of code (30% less or so)
- is more stable
- is easier to maintain
- is much faster!
