Using Next.JS and Redux for Epic Noscript Web Apps

Hi, my name is Daniel and I'm a web developer and a privacy enthusiast based in Oslo, Norway. Thank you for tuning in to this talk about using Next.js and Redux for epic no-script web apps, which will be a short exploration of a method that will enable you to develop applications that work without JavaScript enabled in the browser while still enjoying the benefits and convenience of modern web technologies when making them.

Right off the bat, I want to show you this. This is your standard TodoMEC application, where you can add stuff, edit stuff, check stuff off, filter them and clear them. And here it is again. And I want you to pay close attention and see if you can spot any difference. So we can add stuff, we can say whoops, and edit stuff, check off stuff, apply some filters and we can clear them. So, notice anything? Well, this last one was entirely without JavaScript in the browser. And what's so exciting is that this was both the exact same React application, the exact same HTML rendered to the DOM. And I find that pretty cool, that we can have one application that seamlessly works both with and without JavaScript.

But why would anyone disable JavaScript in the first place? Well, there are several reasons, actually. One of them is performance. When there's no JavaScript running in the background, then your computer has more resources to do other stuff. Another one is fewer popups. When you disable JavaScript, you don't have any of the pull screen newsletter signups or slides up from the bottom, scroll hogging or content that are suddenly applied to the website that makes the scrolling jump and stuff like that. You also have faster load times, as obviously you're not loading the JavaScript, so the page will load faster. And a contributing factor to that is that you're not loading the tracking scripts and the ad networks that in themselves aren't really wanted most of the time. Some users will also disable JavaScript because of increased security. There are examples in the past where ad networks have been used as an attack vector for browser vulnerabilities. And by disabling JavaScript, you avoid them and you also avoid stuff like cross-site scripting. I run a wishlist service called Wishigift. And back in 2018, I added this to the task list, make the site work without JavaScript. Because it's a privacy-friendly wishlist service, and I figure that maybe our most privacy-minded users would like to have an experience that works without JavaScript. And also it's nice to be able to post something on Hacker News without the comments saying that this doesn't work without JavaScript. But also because it's the kind of website that can work without JavaScript or perhaps even should, I don't have any WebGL experiences, or I'm not using any web APIs in a heavy way. It's basically a glorified CRUD application, as are many other applications. And I think that those kinds of websites that can work without JavaScript also should. But I had no idea how. I was using Redux for absolutely everything. And I also dabbled a bit in server-side rendering.

So I just started some background processing. Asked myself, what's available when JavaScript is disabled? It's just HTML and CSS. Okay. How can I convert this already existing application to one that works without JavaScript? No idea. And how can I do it in a way that's maintainable? Because I didn't want to have two separate codebases that would need to be maintained.

Well, fast forward to 2020, and I think I wake up one day, and my mind has put some pieces together. I realized that one of the tenets of Redux, which is thou shalt only put serializable values in state or actions, goes very well with, or actually aligns perfectly with a certain type of payload that's also serializable. Well, talking about forms, the solution was there all along. Instead of having standalone buttons, I could simply wrap them in a form and prevent default on the submit so that if there was JavaScript enabled, the event would be prevented. And if there wasn't, well, it just hit the server and we can have our server dispatch whatever action that we want to perform.

So instead of having just a simple click handler on a button, instead we do something like this. We wrap it in a form and set the action to just an empty string so that when you submit this form, it's going to be sent to the same route that we're already at, which means a view route. And we make the assumption that the only reason why anyone would ever do a post request to a view routes is because they are submitting this kind of form that wraps an action that they want to perform. And inside it, we embed the current state or the client state, the app state and also the kind of action that we want to be dispatched. And we will replace our button type button with a submit button. And you can also omit the type attribute here.

Then in our app.js, if you're using Next.js that is, we have this get initial props, and we check for if this is a post request, well, then we want to read the body and the body will look something like this. It'll have an action type, for example, and the state. And we pass that along to a helper function. Now we'll parse the payload. Using the callback that we supplied, getReduxStore, it'll take the parsed state in the payload and create a new ReduxStore with that. And also dispatch the action in the payload to that ReduxStore and return the updated ReduxStore and the updated state. Then we can assign that to our preloaded state and re-render our application with that state.

So when JavaScript is enabled, user clicks the button, the event is prevented and the action is dispatched. State is updated and the React application re-renders client side. And it's quite similar when JavaScript is disabled, except that we can't prevent default. So the request will hit the server and our server will parse the payload and dispatch the action, get the updated state and re-render the React application server-side. And in both scenarios, the end result is the exact same. The state you end up with is exactly the same. And also, the HTML is exactly the same.

To help us with this, I've created some React helpers that I've added in an npm package. And the most important component is the form component that embeds the state. It selects the state from the Redux and embeds it into the form. And also handles the submit. Which means preventing defaulting on the client side and parsing the payload. Because instead of just passing objects, we're actually typing out all the... We're serializing both the action and the payload into the form. So it parses the form payload and also dispatches any action contained within.

We also have a button, which is a simple helper that just takes a button and wraps it in the form component. And also passes along the necessary props. And you can find this on at witchy-gift.com. But I hear you. First of all, you were promising epic webapps. And second of all, how would you do it with async actions? Well, I got a solution for that as well. Who'da thunk?

So here we have a pretty simple application that enables you to search for epics. So we can search for Homer or we can just do an empty search and list all the epics on the project Gutenberg. And so client-side, this is talking with a third party API called Gutendex. You can see we have this spinner and stuff, and you can also see in the top right here, we have an indicator saying if this page was loaded on a GET request or a POST request. Now, in a no-script scenario, instead of simply telling the server to dispatch an action, that wouldn't do. It wouldn't suffice because we're having async actions. So we actually need to call and await the action creator. And as you'll see, this also works perfectly fine. You can see this time it was done with a POST request and everything works. The functionality is exactly the same. We don't have any spinner, of course. We don't have any loading indicator because we don't have any JavaScript to trigger that with. But that also shows that when you have JavaScript enabled, feel free to add any extra juicing that you might find suitable. It's just that essential interactions need to work without JavaScript. So what happens here, is that instead of dispatching an action, or telling the server to dispatch an action, we're passing along the name of an action creator. And we have a mapping from action creators to their functions.

And when there's an action creator, the server will notice that and just await the dispatch of the action creator.

And now for some exciting live coding. Okay, so here's a simple counter app. So it can increment, it can decrement. You can also set a custom amount and increment and decrement by that amount. But now if we disable JavaScript, you'll see that nothing works. And that is because we're using JavaScript for all of this.

Let's just change this into dev mode. And you can see we have all these callbacks and onClick handlers. So let's make this work without JavaScript. First of all, let's get rid of everything we don't need, which is all the callbacks. We won't be using any onClick handlers, nor will we be needing the onChange and the value here. Then let's import our helper components. Let's import the button and let's import the form. And let's just comment out this bottom part so we can fix that later.

So first of all, we'll change these normal buttons to... Sorry, I also forgot we have to remove this type button because we want these to actually submit the forms. So let's change these buttons to the button component. And our first one should... So the button component takes in an Action. And our first one should be the decrement Action. And our second one should be the increment Action. Let's see here if this works. So we can decrement, we can increment. Nice. Okay. And if we disable JavaScript... So, first of all, the styles disappear because Next.js doesn't really like having JavaScript disabled in development mode. But our functionality still works, which is the important part. And I'll show you later the styles in a production build.

It works as you would expect. Okay, so we got that working and it was just a tiny change. This is less code than before. We just added the action that we wanted to submit and used the button component instead of a normal button.

So, for this part, where you can select your own amount, we'll just change this wrapper to be our form component. And then we want to actually use these normal buttons. But we want it to be so that when you press the first button, it will use the value from this input and decrement by that amount. And if you press the second button, we want to use this value again but increment. And we can do that by saying that the button should have name action type and the value of decrement by amount dot type. And what will happen here is that when the form is submitted by pressing this button, only the value of the submitted button will be in the payload itself and client side on the event dot submitter. So we do the same here. We say that name should be action type, which corresponds to the name of the action, should in this case increment by amount dot type. And we also have to say that the payload is this number input. Let's try. OK, sorry. We also have to specify that the payload should be JSON. So now this works correctly. And if we disable JavaScript as well, that also works. Cool.

But I want to add one last thing. I like surprises. So let's add a little surprise as well. Let's give this some styles. And we'll add a button here with the class name of button and surprise. So I want to add a random number between minus 50 and 50. And we can do this by using the action of course, and increment by amount. And pass in, just some quick math here. Get a random number, multiply that with 100, and subtract 50, and if we check this out, this works beautifully. And... If we disable JavaScript, this also works.

Great. But the thing is that if you decide to refresh the page, you'll see that we get the exact same number every time. And that's because we're resending the exact same state and we also hardcoded the random numbers. And that is also being resend when we resubmit the form. That's not very surprising, is it?

So instead of using just an action, we'll just pass the name of an action creator. And I made this called increment by surprise. And if we click that, we'll see we still get a random number. And if we disable JavaScript and we refresh, we get a new random number each time. Because now the action creator is being run server side, which regenerates the random number every time. And I wanted to show you this as well. If I actually do a production build here and start the server, you see that the styles actually work without JavaScript as well. So it's just in dev mode.

OK, so there are some caveats with employing this method. And one of them is that you can't have any essential interactions usable only through JS events. So you can't have any, as I said, essential interactions behind things like a hover, or drag and drop, or a long press, and stuff like that. And there's some extra markup that you have to consider when styling because we're adding forms everywhere. There's also lots of refreshing. And I'd say that this isn't really a caveat or an issue. Because oftentimes, for a user without JavaScript enabled, the alternative would be no application or just no updates. And there's an increased server load because we're telling our server to handle more stuff, dispatch actions, and more re-renders that we can't optimize like we can the static GetPages. And when you add GetInitialProps to your Next.js pages, you lose some optimization, which is also sad. I wish there was a way to only enable the GetInitialProps on Post requests, so maybe that'll come someday. Fingers crossed.

And to summarize. By leveraging forms and an event-based store, we can have one application that will seamlessly work whether or not the user has JavaScript enabled in the browser or not. And we can use some helper components to make our lives easier when developing an application like this. But this implementation in itself might not be perfect. I'm well aware of that. What I'm presenting to you is simply a generalized approach or a way of thinking about making applications that work without JavaScript. And if you know of a better way or can think of a better way, or have suggestions and ideas on how to improve this, I'd love to hear them. And please reach out to me. I'm at Portrait2K on Twitter and everywhere. And I'd love to hear what you've done and if you're using this and what do you think about it. So thank you for watching this talk. And big thanks to React Advanced for having me.