DEV Community: Zach Taylor

K-Means Clustering

Zach Taylor — Mon, 01 Jan 2024 20:49:20 +0000

I wrote a new post about clustering algorithms on my personal blog. It would be a bit difficult to write here since there's a lot of math, so here's the link: https://zachdtaylor.com/blog/k-means-clustering.html

If you have any comments, feel free to leave them here :)

A Phoenix LiveView is Just a Process

Zach Taylor — Fri, 17 Mar 2023 23:29:47 +0000

I want to write a quick post about this paragraph in the LiveView docs. It says

A LiveView is just a process that receives events as messages and updates its state. The state itself is nothing more than functional and immutable Elixir data structures. The events are either internal application messages...or sent by the client/browser.

I didn't really get what this meant at first. It's not that this paragraph is worded poorly or anything, I'm just relatively new to Phoenix and LiveView and I had to work through an example on my own to understand it fully. I want to share that example here.

So first, a bit about Elixir processes.

Elixir apps contain one or more processes. Processes can spawn other processes. For example, if you open up an iex shell, you can spawn a new process that runs this greet function

defmodule Greet do
  def greet(name) do
    IO.puts("Hello, #{name}!")
  end
end

with spawn(Greet, :greet, ["friend"]). This will print Hello, friend! to the console and will return the pid of the newly spawned process.

You can also send messages to processes with the send/2 function, and those processes can receive messages with receive. For example, we could change our module to

defmodule Greet do
  def greet(name) do
    receive do
      :print -> IO.puts("Hello, #{name}!")
    end
  end
end

Now if we spawn a new process that runs the greet function with pid = spawn(Greet, :greet, ["friend"]), we won't immediately see the message printed to the console. We can tell that process to print the message with send(pid, :print).

You can also register processes with a name so you don't have to always refer to them by their pid. For example, we could run

pid = spawn(Greet, :greet, ["friend"])
Process.register(pid, :greeter)
send(:greeter, :print)

Registering the pid with the name :greeter lets us send the message using that name instead of the pid.

So, let's bring this back to LiveView.

As that paragraph in the documentation says, "A LiveView is just a process". As such, we can send it messages, just like we could with any other process.

The cool thing about LiveView processes is that they maintain their own state, and whenever something updates that state, the LiveView process re-renders its html template and pushes the changes to the browser.

Say we have a LiveView module that looks like this (this is on version 0.18.16, btw)

defmodule MyAppWeb.IndexLive do
  use MyAppWeb, :live_view

  attr :name, :string, default: "stranger"

  def render(assigns) do
    ~H"""
    <div>
      <p>Hello, <%= @name %>!</p>
    </div>
    """
  end

  def mount(_params, _session, socket) do
    Process.register(self(), :index)

    {:ok, socket}
  end

  def handle_info({:update_name, name}, socket) do
    socket =
      socket
      |> assign(:name, name)

    {:noreply, socket}
  end
end

When you visit this LiveView in your browser, mount/3 is called, where we register the new LiveView process with the name :index. (If you didn't know, self() in Elixir refers to the pid of the process that that line is being executed by, which is, in this case, the LiveView process)

So when you visit this LiveView in your browser, you'll see the message "Hello, stranger!", and the LiveView handling your browsing session is registered under the name :index.

Now, a LiveView maintains its state in a variable it calls socket, and it responds to messages from other processes in the handle_info function (as opposed to the receive block in our earlier example). So, whenever we send a message to the LiveView process, that process calls handle_info, which updates its state by setting the :name property.

If you run your application with iex -S mix phx.server, then you'll be able to go into the iex console and send a message to the LiveView process. The only message that our LiveView process handles is one of the format {:update_name, name}.

So if we say send(:index, {:update_name, "partner"}) in the console, the LiveView process will handle that message in handle_info, which updates the process's state, which then updates the UI in the browser to read "Hello, partner!". Pretty cool!

Going through this example helped me to grasp the fact that a LiveView is just a process that maintains your UI state. When you update that LiveView process's state, it re-renders the html and sends the diff to the browser.

Some Thoughts on Server State in Remix

Zach Taylor — Sat, 08 Jan 2022 00:37:48 +0000

(you can also read this here)

I was at a Remix meetup in Utah last night. At the meetup, Kent gave a talk in which he said that one great thing about Remix is that he doesn't have to think too much about state when using it. Afterwards, someone at the meetup asked me what he meant. It seems weird that you wouldn't have to think about state. Isn't state, like, a huge part of building an app?

To answer this question, it's important to know that it's not that you don't use state when building a Remix app. Rather, the framework just takes care of a lot of it for you. Here's what I mean by that.

A huge source of state in React applications is server state. The typical way to handle server state is to fetch it from the server with JavaScript and then use React Query or something similar to cache the resulting data client-side. All of that requires thought on your part. You need to understand how to use whatever caching library you're using. If you make a data mutation, you have to keep track of which queries/data to invalidate. You need to show error messages if there's an error. It's a lot to think about.

With Remix, you don't have to think about any of that. All you have to do is return the data you need in your loaders and grab that data with useLoaderData. When you send a mutation, you don't have to invalidate anything; the data on the page gets updated automatically. When you define CatchBoundary and ErrorBoundary components for error handling, you don't have to think about when to render them; Remix will render them at the right time for you.

So how exactly does this work? Where does Remix store the data for the page? And how does Remix know when to update it?

If you don't have JavaScript on the page, then there's nowhere for Remix to store the data. The HTML page itself is effectively the "store", and when you mutate data with a form, the page is refreshed, a server-side render happens, and you get refreshed data. This is how browsers work by default.

If you have JavaScript on the page, then Remix stores your data in a global context and provides a few ways for you to access it.

The first way, as mentioned, is useLoaderData. This hook will grab the data returned by the loader for the specific route you call the hook from. For example:

// routes/recipies.tsx
export const loader: LoaderFunction = () => {
  // return some data
}

export default function Recipies() {
  // This will grab the data returned from the above loader.
  const data = useLoaderData();

  // Or, you could move the `useLoaderData` inside
  // `RecipieCard` instead of passing `data` as a prop.
  // Since the `Recipies` route is the closest to
  // `RecipieCard` in the component tree, 
  // you'll get this loader's data.
  return <RecipieCard data={data} />
}

The second way is useMatches. This hook will give you all the data for every route that matches the current URL, so you can grab the data for any route that is currently rendered on the screen.

There is also a third way that might be added to Remix in the near future, called useRouteData. This hook will allow you to get data from a specific route by passing a route id.

You can also grab data from any loader (even ones that are not part of the current route) with useFetcher().load. However, unlike useLoaderData and useMatches, this data will not come from the global context and instead, useFetcher().load will send a network request to get the data and store it locally, just like you might do with fetch.

If you submit a form with <Form /> or call an action with useFetcher().submit, Remix will call all the loaders for the current route and update the global context for you. You don't have to think about it! What's cool about this is that Remix is just emulating regular browser behavior here. Again, if there were no JavaScript on the page, the browser would do a full page refresh, which would call all the loaders for the current route, and you'd get a fresh HTML document with fresh data. This is exactly what Remix is doing, just with JavaScript so there's no page refresh.

And for error handling, all you have to do is export an ErrorBoundary component for unexpected errors, and a CatchBoundary component for errors you throw yourself, and if there are any errors, Remix will display the error UI in place of the regular UI for that route automatically, without you having to think about it.

Doing things the Remix way does require a bit of a mindset shift. You have to think about data and errors in terms of your routes. Whenever you call useLoaderData, you will get the data for the nearest route in the component tree. The ErrorBoundary and CatchBoundary display in place of the UI for whatever route they're defined in. But reframing things in terms of routes enables a lot, and it's what makes Remix so special and easy to use.

Thanks for reading.

Progressive Enhancement in Django vs Remix

Zach Taylor — Wed, 22 Dec 2021 03:55:38 +0000

In this post, I want to tell you a quick story about one of the reasons I love Remix: super simple progressive enhancement.

A couple years ago, my team at work was tasked with creating a new application that would be used internally by our sales reps. The tool needed to allow reps to quickly search through our available products and build quotes to send to customers. For various reasons, we decided to build the app with Django.

Django is awesome. One thing I love about Django (and similar frameworks like Rails) is that you render your HTML server-side. The way you do this in Django is with their Django template language, which is an extension of HTML that allows you to reuse HTML files, and embed if statements, for loops and other custom logic. Rendering HTML server-side means you can talk directly to your database and you don't have to create "API routes" to retrieve data from the browser with JavaScript.

In fact, you don't have to include any JavaScript at all in your app if you don't want to. In Django, you use HTML forms for user input, which is enough to create a functional app. This is what the first version of our quoting app at work did. There was no JavaScript; it was just server-rendered HTML with HTML forms for data mutations.

However, the sales team started asking for the fancier user experiences that are expected from modern applications. In other words, they were asking for some progressive enhancement. These modern user experiences simply can't be done without JavaScript on the page, and this is where Django's SSR model kind of left us hanging.

JavaScript kind of feels like an afterthought in Django. Django's solution to JavaScript is to just do what you do on any web page: write some JavaScript in a file and include it with a <script /> tag in your HTML. The nice thing about this is that you have full control over which JavaScript files are loaded on any given page, so your network tab stays clean.

The problem with this approach is that you end up writing a lot of your server-side logic again in your JavaScript. For example, in a To-Do app, you might have a list of to-dos and a detail view that changes as you click on each one. If you want the ability to switch out the detail view client-side without making a full document request, you'll have to write some JavaScript to 1) make a request to your server to get the to-do data and 2) manually replace the old detail view in the DOM, thereby duplicating some of the render logic that was in your Django template. This also means you have to add an API route for the JavaScript to talk to. This one example is not a ton of extra work, but it can add up quickly and get messy if you need a lot of interactivity.

We eventually needed enough interactivity in our quoting app that it was pretty difficult to maintain. We decided it would make our lives easier as developers to convert the entire front end to a React SPA and just use Django for the API routes and talking to the database. This solved our maintenance problems, and handling data was made easy with React Query, but I still felt like we had lost something.

For one, we were now sending a lot more JavaScript across the network because all of our app logic was now client-side. For two, we now had request waterfalls and spinners all over the place, instead of a single document load with all the data already there.

It was around the time I was thinking about these problems that I heard about Remix. I bought a supporter license and dove in, and I immediately knew it was the solution I was looking for.

Remix gives you all the benefits of server-side rendering while also making the transition to interactivity on the client completely seamless. All it takes is one <Script /> element in your root route and boom, your app is now running React in the browser, doing client-side route transitions. There's no need to write any new logic at all. No extra JavaScript, no API routes, nothing. This is due to a couple things. First, since React can render HTML on the server and run in the browser, you don't have to re-create your server-rendering logic on the client. So instead of using a template language on the server and JavaScript in the browser, I can just write React code once and use it in both places. Second, Remix takes care of creating and calling API routes for you. Your loader functions are used during the initial server render, and they are automatically made available as endpoints and called from the client on page or layout transitions.

Remix also lets you control which pages are interactive. If one page needs JavaScript but another doesn't, you can include JavaScript only on the page that needs it. This allows me to retain a lot of that control over the network tab that I had in Django.

If you want to get fancy with forms and do form submissions client-side without a document refresh, you just have to switch from <form> to Remix's <Form>. Remix will then prevent the default refresh behavior, call an endpoint that runs your action for that route, and call all the loaders for that route so the data on the page stays up to date. It's the same behavior the browser gives you, but without the page refresh!

And therein lies the reason I love Remix's approach to progressive enhancement so much. Remix doesn't stray too far from the default browser behavior, which not only means you can fall back on default browser behavior if your user has a spotty connection and JavaScript fails to load, but you also learn to think in terms of how the browser behaves, which is transferrable knowledge you can use outside of Remix.

There are so many things I love about Remix, but the way it makes progressively enhancing apps with JavaScript so easy is one of my favorite things about it. Thanks for reading. 🙂

Photo by Andy Holmes on Unsplash

An Intro to HTML Forms

Zach Taylor — Thu, 07 Oct 2021 13:25:29 +0000

Photo by Esther Jiao on Unsplash

What is a form?

According to MDN: an HTML form represents a document section containing interactive controls for submitting information.

In other words, it's the thing in your web page that lets users communicate with your server.

Wait, isn't that what JavaScript is for? JavaScript is capable of many things, including sending/asking for data from your server. And these days, yes, most websites do all of that communication with JavaScript.

Originally, however, communication with the server was done in HTML with forms. This is because back in the day, pretty much all websites were server-rendered and most didn't have much JavaScript on the page, if any at all. The user would hit the URL to your site, which would trigger some PHP script to put together an HTML document, and that document would be sent back to the user's browser and displayed. If you wanted the user to be able to send data back to your server, you would include a <form> in the document with inputs for them to interact with. When the user submits the form, that server-side PHP script would process the form data, put together a new document and send it back to the browser, which would then refresh, showing the user the new state of the page. It wasn't until AJAX (Asynchronous JavaScript And XML) was invented that people started making requests and updating the DOM client-side with JavaScript.

With that history lesson out of the way, let's dive in! HTML forms are pretty simple to create: use a <form> tag, with <input> tags inside of it, like this.

<form>
  <input type="text" name="name" />
  <input type="email" name="email" />
  <input type="submit" />
</form>

Add some labels,

<form>
  <div>
    <label for="name">Name</label>
    <input type="text" name="name" />
  </div>
  <div>
    <label for="email">Email</label>
    <input type="email" name="email" />
  </div>
  <input type="submit" />
</form>

and with a bit of CSS you have something that looks like this:

The <form> element has a few parameters that allow you to customize its behavior. I'll go over the most commonly used parameters in this post.

The `method` Parameter

By default, the <form> element sends data in query parameters via a GET request to the current URL. Let's assume your page is hosted at localhost:3000. If you were to fill out the form we created above like so,

clicking Submit will make a GET request to

localhost:3000/?name=zach&email=zach%40gmail.com

If you don't want to use the GET method, you can choose to send a POST request with the method parameter:

-<form>
+<form method="post">

In this case, the browser will make a POST request to the current URL with the form data in the request body.

Customize the POST body with `enctype`

The structure of the POST body depends on the form's enctype. By default, enctype="application/x-www-form-urlencoded". With this enctype, the body will take the form of a URL encoded string as you can see in the dev tools here:

Another option for enctype is multipart/form-data. This value should be used if you want to send a file to the server with an <input type="file" />. If you keep the default enctype, the file won't actually be sent; the form will just send the file name as a string.

The third and final enctype called text/plain, and it sends your form as plain text that looks like this:

name=zach
email=zach@gmail.com

According to MDN, text/plain is mainly for debugging purposes.

Other HTTP methods

GET and POST are the only two HTTP methods you can use with forms. The other methods (PUT, PATCH, DELETE, etc.) will not work; the form will default to sending a GET request.

There's a fun little trick you can do, though, if you want to send a request to your server with one of the other methods. Simply put a hidden input in your form whose value is the method you want to use:

<form>
  <input type="hidden" name="_method" value="DELETE" />
  <div>
    <label for="name">Name</label>
    <input type="text" name="name" />
  </div>
  <div>
    <label for="email">Email</label>
    <input type="email" name="email" />
  </div>
  <input type="submit" />
</form>

Then, on your server, you can parse the form data and check the value of the _method field to determine which type of request was sent.

The `action` Parameter

What if you want to send the form data to a different URL? You can set the action parameter:

<form action="https://zachdtaylor.com/">

Try it out! When I submit the form, I'm taken to my website, with some additional information appended to the URL:

https://www.zachdtaylor.com/?name=zach&email=zach%40gmail.com

One situation where this would come in handy is if you wanted to redirect the user to someone else's site with some state passed in. For example, with this form, you can search Kent C. Dodd's blog on his new website:

<form action="https://kentcdodds.com/blog">
  <div>
    <label for="q">Search Kent's Blog:</label>
    <input type="search" name="q" />
  </div>
  <input type="submit" />
</form>

Pretty neat! A form with an action argument is actually pretty similar in behavior to what a link does.

<a href="https://zachdtaylor.com" />

<!-- Same behavior! -->
<form action="https://zachdtaylor.com">
  <input type="submit" />
</form>

🤯

Conclusion

If you're interested in getting to know forms a little better, try building something in the Remix web framework. They are embracing the old model of talking to the server with plain old HTML forms, and honestly it's a wonderful experience.

I hope this was helpful. Thanks for reading!

Stable Forms in Remix

Zach Taylor — Tue, 15 Jun 2021 21:51:28 +0000

Data mutations in Remix are done with HTML forms, and Remix allows you to upgrade your forms with JavaScript to provide a better UX.

Like anything in the UI, forms might be used in a way you don't expect. What happens if the user spams the submit button and causes several form submits? If you don't handle this, users could inadvertently (or intentionally) break something. In this post, I want to talk about how you can make your forms more stable and less susceptible to these types of problems. I'll use my Twitter dashboard app from my last post as an example.

Case 1 - The Native HTML `<form>`

In the case of the native HTML <form>, you don't really have control over what happens client-side; it's up to the browser. Some (all?) browsers take measures to ensure that a form can't be submitted again while the first submission is still pending.

For example, in Chrome, if you type something in the search bar and submit the form 3 times quickly, the browser automatically cancels the first two requests and only sends the last one.

It's nice that Chrome takes care of cancelling the first two requests for us. I'm not sure if this behavior is consistent across browsers. In any case, you'll want to make sure that your Remix actions and loaders can safely be called multiple times with the same form data / search parameters.

For example, if the user submits a form several times to delete something, you'll want to handle errors that may arise from deleting something that's already been deleted. If the user submits a form several times to create something, you might want to make sure they can't create multiple copies.

A lot of how you handle this depends on the nature of your app, which is why I'm being kind of vague. Just make sure you handle multiple form submits on the server in a way that makes sense for your app.

Going on kind of a tangent here, but handling things well server side is always important because in the end, we don't really have control over how a request arrives at our server. We only have control over what we do with it.

The conclusion here is that if we use the native <form> (or if the user has JavaScript disabled), there's nothing we can really do but leave it up to the browser on the front end and make sure we handle things server-side in a secure way that makes sense (which we should be doing anyway 😄).

Case 2 - Remix's Enhanced `<Form>`

Now say we want to upgrade to Remix's <Form>, taking control out of the browser's hands and putting it in ours with JavaScript. If we simply change <form> to <Form>, the user will be able to submit the form again while the first submission is still pending. This is not ideal, because we are now putting more load on our server and probably slowing down the user's browser.

A lot of people's first instinct in this case is to disable the submit button while the form is pending. The problem with this is that disabling a button is not app logic, and the user can get around it. For example, the user might submit the form with their enter key. Good luck disabling that button! 😜

A more stable pattern is to treat the form as a state machine! The state machine in this case is quite simple. The form starts in an idle state, and when the user submits the form (by whatever means they choose), it goes to the pending state. While in the pending state, it should be impossible to submit the form again. Then, once the response comes back, the form goes back to the idle state and can be submitted again.

So how do we implement this state machine in Remix? Remix provides a hook called usePendingFormSubmit that allows us to determine if the form is in the pending state or not. Once we've determined what state the form is in, we can either prevent or allow form submission accordingly, like this.

const pendingForm = usePendingFormSubmit()
const pending = !!pendingForm

...

<Form onSubmit={(event) => pending ? event.preventDefault() : null}>
  ...
</Form>

In Remix, calling event.preventDefault() prevents the form from submitting (this is the exact same way you prevent a regular HTML form from submitting, by the way!). So our logic is: if the form is in the pending state, call event.preventDefault() and prevent the form submit. If the form is in the idle state, do nothing and allow the form submit.

Now the app logic is solid and will prevent re-submission whether we disable the submit button or not, or if there's no submit button at all!

Here is a full demo of everything discussed above.

I hope this was helpful!

Photo: engin akyurt on Unsplash

Building a Simple Search UI with Remix

Zach Taylor — Wed, 02 Jun 2021 03:18:42 +0000

Photo: Markus Winkler on Unsplash.

One thing I love most about Remix is how it encourages you to take advantage of native web APIs. One such API is the native HTML <form>. In this post, I want to show you how you can use an HTML form in Remix to build a simple search UI.

The project I'm working on right now is a Twitter dashboard app. One of the features of the app is that it lets you schedule tweets to be sent at a later time. Here's what the tweet scheduler looks like:

You'll notice that we have a side bar containing all your scheduled tweets, and a large area on the right where you can see the contents of the tweet you clicked on. There is a search bar at the top of the side bar that lets you filter your scheduled tweets with a search query. That search bar is what we'll be implementing in this post.

The Route

If you're not already familiar with Remix routes, basically a route represents a piece of the UI. But a route isn't just the UI; it's the data, styles, meta tags, form handlers, and everything else associated with that UI. Each route and all its pieces is defined by a file in your source code.

The data piece of a route is defined by an exported function called loader. The loader will be called every time a GET request is made to that route.

In the Twitter dashboard app, the side bar is represented by the route /schedule. When you make a GET request to /schedule, the loader is called, which returns all of your scheduled tweets:



export let loader: LoaderFunction = () => {
  return getAllTweets();
};

You can then use Remix's useLoaderData() hook to grab that data in your component and display it:



export default function Schedule() {
  const data = useLoaderData();

  return (
    // Map through tweets and display them
  )
}

The Search Bar

So, the search bar. When building something in Remix, the first thing to do is ask, "how does the browser do this by default?" Well, browsers are capable of sending requests to your server using forms. By default, an HTML <form> sends data in the search parameters of a GET request to the current URL. So, if we wrap the search bar in a <form> like this



<form>
  ...
  <input type="text" name="query" placeholder="Search tweets..." />
</form>

then the user will be able to type a search query, and upon hitting enter, the form will make a GET request to /schedule?query=query_goes_here

Remember that a route's loader is called every time a GET request is made to that route, so to filter the tweets, we just need to grab the search query from the URL in our loader and filter the data accordingly!



export let loader: LoaderFunction = ({ request }) => {
  const url = new URL(request.url)
  const search = new URLSearchParams(url.search);
  return getAllTweets(search.get("query")); // Filters tweets based on the query
};

Something I really like about this is that the state of the app is encoded in the URL. You can hand someone the url /schedule?query=Remix and the list of tweets will automatically be filtered to ones that contain the search word "Remix".

One little snag, though, is that the UI won't be completely in sync with the URL if you go directly to /schedule?query=Remix because the search bar renders blank by default. This can easily be fixed, though! React Router provides a hook to grab the URL search params, which you can then pass as the defaultValue of the search bar:



export default function Schedule() {
  ...
  const [params] = useSearchParams()

  return (
    <form>
      <input type="text" name="query" placeholder="Search tweets..." defaultValue={params.get("query")} />
    </form>
    ...
  )
}

Now if you go straight to /schedule?query=Remix, the search bar will render with the word "Remix" already filled in.

Upgrading to `<Form>`

By default, an HTML <form> will trigger a full page refresh when submitted. Because we're passing a defaultValue to the search bar, the search query will still be there when the user hits enter. However, they will lose focus of the search bar since they're getting a brand new document. It would be nice if the user didn't need to click on (or tab over to) the search bar again after hitting enter.

Thankfully, Remix makes upgrading your forms super easy! Remix provides a <Form> component which emulates the behavior of the native <form>, but instead of triggering a full browser refresh, simply calls the loader directly with a JavaScript fetch. So all we need to do is replace our old <form> with Remix's <Form>.



import { Form } from "remix"

// In the component
<Form>
  ...
  <input type="text" name="query" placeholder="Search tweets..." defaultValue={params.get("query")} />
</Form>

Voila! No more page refresh, and no more losing focus of the search bar.

Persisting Across Route Transitions

One final problem we have is persisting the filtered results across route transitions. It would feel weird to filter the tweets with the search bar, click on one, and suddenly have the tweets go back to being unfiltered.

Since the list of tweets depends on the URL search parameters, we just need to make sure the search parameters stay in the URL when we click on a tweet. React Router allows you to pass search parameters to a <Link> or <NavLink> component like this:



const location = useLocation()

...

// when rendering the tweets:
<NavLink to={{ pathname: id, search: location.search }}>
  ...
</NavLink>

Now the list of tweets will stay filtered when you click on one.

Conclusion

Here's a working demo of the search bar:

I hope you found this post helpful in one way or another. If you haven't tried Remix yet, you definitely should!

Improving Your React Code - Custom Hooks

Zach Taylor — Sat, 13 Feb 2021 21:39:53 +0000

One of the main reasons I, and many others, love React is that it allows us to organize markup into reusable pieces.

Custom React hooks allow us to do the same thing with application state.

I think the name custom hooks can make them seem more complicated than they actually are. A custom hook is just a function that happens to call some special functions in the React library.

Because they are just functions, they can do all the things functions can do. They are reusable, and they can help you maintain separation of concerns in your application, resulting in clean, maintainable, easy-to-read code.

Let's look at an example.

An Example

React applications typically need to do some asynchronous tasks. Say we need to generate a PDF and render it in an iframe. The process of generating a PDF can take a few seconds, so we'll probably want to start the process, then show some loading indicator while it's running, then display either the PDF or an error message once it's finished. A first attempt might look something like this:

const generatePDF = (contents) => {
  // Generate PDF
  ...
  // Returns a promise
}

const PDF = ({ pdfContents }) => {
  const [{ status, data: pdf, error }, setState] = React.useReducer(
    (prevState, newState) => ({ ...prevState, ...newState }),
    { status: 'idle', data: null, error: null }
  )

  React.useEffect(() => {
    setState({ status: 'pending' })
    generatePDF(pdfContents).then(
      (data) => setState({ data, status: 'resolved' }),
      (error) => setState({ error, status: 'rejected' })
    )
  }, [pdfContents])

  if (status === 'pending') {
    return <Spinner />
  }

  if (status === 'rejected') {
    return <Error message={error} />
  }

  return <iframe title="PDF" src={pdf} />
}

A React component's primary responsibility is to return some markup for React to render, but in this example, we have to scroll past over half of the function body before we get to that point. It feels like the component is doing too much. It's also not immediately clear what the calls to useReducer and useEffect are for.

When a function gets too long and confusing, a good thing to do is to split it up into several shorter, more focused functions. We will likely have more asynchronous tasks to perform in other components, so let's first extract the logic for handling loading, error, and success states to its own function. (The following was inspired by this.)

import React from 'react'

const useAsync = () => {
  const [{ status, data, error }, setState] = React.useReducer(
    (prevState, newState) => ({ ...prevState, ...newState }),
    { status: 'idle', data: null, error: null }
  )

  const run = React.useCallback((promise) => {
    if (!promise || !promise.then) {
      throw new Error(
        `The argument passed to useAsync().run must be a promise.`
      )
    }
    setState({ status: 'pending' })
    return promise.then(
      (data) => setState({ data, status: 'resolved' })
      (error) => setState({ error, status: 'rejected' })
    )
  }, [])

  return {
    isIdle: status === 'idle',
    isLoading: status === 'pending',
    isError: status === 'rejected',
    isSuccess: status === 'resolved',
    run,
    data,
    error,
  }
}

This is a custom hook. Again, I want to point out that it is just a function. It just happens to be called a custom hook in React land because 1) its name starts with use and 2) it calls functions in the React library whose names start with use.

Now we can change the PDF component to this:


const generatePDF = (contents) => {
  // Generate PDF
  ...
  // Returns a promise
}

const PDF = ({ pdfContents }) => {
  const { data: pdf, isLoading, error, isError, run } = useAsync()
  React.useEffect(() => {
    run(generatePDF(pdfContents))
  }, [run, pdfContents])

  if (isLoading) {
    return <Spinner />
  }

  if (isError) {
    return <Error message={error} />
  }

  return <iframe title="PDF" src={pdf} />
}

This is a lot better, but it still kind of feels like the component is doing too much. Let's extract the useAsync and useEffect calls to another function.


const generatePDF = (contents) => {
  // Generate PDF
  ...
  // Returns a promise
}

const usePDF = (pdfContents) => {
  const { data: pdf, isLoading, error, isError, run } = useAsync()
  React.useEffect(() => {
    run(generatePDF(pdfContents))
  }, [run, pdfContents])
  return { pdf, isLoading, isError, error }
}

const PDF = ({ pdfContents }) => {
  const { pdf, isLoading, isError, error } = usePDF(pdfContents)

  if (isLoading) {
    return <Spinner />
  }

  if (isError) {
    return <Error message={error} />
  }

  return <iframe title="PDF" src={pdf} />
}

The PDF component looks so much better. All the work of generating the PDF and handling the loading, error, and success states has been reduced to one line, so the component can focus on rendering markup.

It's now very clear what the PDF component does: it generates a PDF with the provided props, and returns either a Spinner, Error, or the pdf in an iframe. No more trying to decipher the ambiguous calls to useReducer and useEffect.

This is nothing new

If you ignore the fact that we're working in a React application, the previous example should feel very familiar to you. Again, all we're doing is taking one big function and splitting it up into smaller functions that each have a single responsibility.

There's nothing new here, which is what makes custom hooks so powerful. It's just one function (the component) calling another function (usePDF) calling more functions (useAsync and useEffect). React only requires that you follow two rules when calling custom hooks, but besides that, all of your intuition about functions can immediately be applied.

Better Dev Tools

Besides just making your code a lot more maintainable, custom hooks make your application easier to debug by improving what you see in the react dev tools.

Let's take a simple example. Say you were building a user registration form. How would you hold the form state? I see a lot of code that looks like this:

import React from 'react'

const RegisterForm = ({ onSubmit }) => {
  const [username, setUsername] = React.useState('')
  const [firstName, setFirstName] = React.useState('')
  const [lastName, setLastName] = React.useState('')
  const [email, setEmail] = React.useState('')
  const [password, setPassword] = React.useState('')
  const [confirmPassword, setConfirmPassword] = React.useState('')

  return (
    <form>
      <input 
        value={username}
        onChange={(e) => setUsername(e.target.value)}
      />
      ...
    </form>
  )
}

This works fine, but when you open up the React dev tools in your browser, you'll see this:

This isn't very helpful. It's not clear at all that these pieces of state belong to the form.

To make this a bit clearer, we can extract all these useState calls to another function. Better yet, we can also replace all the useState calls with one useReducer call.

import React from 'react'

const useRegisterForm = () => {
  return React.useReducer(
    (prevState, newState) => ({ ...prevState, ...newState }),
    {
      username: '',
      password: '',
      confirmPassword: '',
      firstName: '',
      lastName: '',
      email: '',
    }
  )
}

const RegisterForm = ({ onSubmit }) => {
  const [registerForm, setRegisterForm] = useRegisterForm()

  return (
    <form>
      <input 
        value={registerForm.username}
        onChange={(e) => setRegisterForm({ username: e.target.value })}
      />
      ...
    </form>
  )
}

Now the dev tools are much clearer:

Notice that all of the state in the useRegisterForm hook is shown under RegisterForm. This will happen with every custom hook; a hook named useCustomHook will show up as CustomHook in the dev tools.

How much?

Custom hooks are awesome, but how often should you extract your state to custom hooks?

Honestly, I think you should move state to custom hooks more often than not. As we've discussed, they allow you keep related pieces of state together which improves the readability of your components. And with the added benefits of being reusable and improved dev tools, it's hard to justify not using them all the time.

Conclusion

It took me a while to figure out how helpful custom hooks are, but once I did, I never looked back. I use them all the time now and my code is much better for it. If you haven't been using custom hooks in your applications, I highly recommend you start.

How to Add Custom Fonts to a GatsbyJS Site

Zach Taylor — Tue, 03 Nov 2020 05:00:27 +0000

Today, I successfully added a custom font to a Gatsby site I'm working on. The process is pretty simple! Here it is in 4 steps:

1) Create a folder src/fonts/ and put your custom font files in it (mine was called Timeless.ttf).

2) Create a global CSS file at src/css/index.css.

3) In the global CSS file you just created, write the following:

@font-face {
  font-family: 'Timeless';
  src: url('../fonts/Timeless.ttf');
}

html {
  font-family: Timeless;
}

4) In your gatsby-browser.js file, import the global CSS file.

import '.src/css/index.css'

And there you go :)

pyp - A pip wrapper that writes requirements for you

Zach Taylor — Tue, 29 Sep 2020 22:17:27 +0000

Have you ever installed a package with pip in your Python project and realized later that you never added it to your requirements.txt? I know I have, which is why I recently created an open source project that I call pyp to fix that. It's a thin wrapper around Python's package manager pip that writes your requirements.txt file for you as you install packages.

To install pyp run

$ pip install pyp-manager

You can then install a package with

$ pyp install pip-install-test

and a requirements.txt file will be created in your working directory with pip-install-test==0.5 on the first line.

Right now, pyp only works in Python 3 and it relies on the pip command being available.

If you want to contribute, check out the repository at https://github.com/zachtylr21/pyp.

Photo by George Stewart on Unsplash

Inheritance in JavaScript

Zach Taylor — Tue, 29 Sep 2020 17:28:51 +0000

As someone who learned to code in C++, JavaScript was confusing to me when I first started learning it. One of the main reasons for my confusion was that the object-oriented concepts I was used to were seemingly nowhere to be found. Sure, you could create objects in JavaScript, but to me, they seemed more like a map in C++ or a dict in Python.

I certainly didn't understand how inheritance could work, and for a while, I just assumed that inheritance wasn't possible in JavaScript. Turns out, inheritance is possible in JavaScript, but it is done through the use of prototype objects.

Prototype Objects

The Mozilla docs explain prototype objects like this:

When it comes to inheritance, JavaScript only has one construct: objects. Each object has a private property which holds a link to another object called its prototype. That prototype object has a prototype of its own, and so on until an object is reached with null as its prototype. By definition, null has no prototype, and acts as the final link in this prototype chain.

So, in JavaScript, there is no such thing as a class in the traditional sense. There are only objects. Each object has an attribute called a prototype that you can access via obj.__proto__. When you try to access an attribute on an object instance, JavaScript will first check the attributes of that object. If the attribute is not found there, it will check the object's prototype, then the prototype's prototype, and so on, until it finds the attribute or reaches the end of the prototype chain.

An Example

To define an object type in an object-oriented language like Java or Python, you would create a class and give it a special method called a constructor. For example, to define a Product object type in Java, you could write

public class Product {
  double price;

  public Product(double price) {
    this.price = price;
  }
}

To define an object type in JavaScript, you only create the constructor. For example, we could create a Product constructor like this.

function Product(price) {
  this.price = price
}

To create a new object using the Product constructor, you would do

let product = new Product(10)

When you call new in this line, the variable product gets injected as this in the Product constructor. Therefore, if you log the output of product.price you should get 10.

Now what if we wanted to add a method to all instances of Product? In Java, we would add a method to the class, like this.

public class Product {
  double price;

  public Product(double price) {
    this.price = price;
  }

  public String sayPrice() {
    return "I cost $" + String.valueOf(this.price);
  }
}

In JavaScript, we add the method as an attribute on Product's prototype.

Product.prototype.sayPrice = function() {
  return `I cost $${this.price}`
}

We could now call sayPrice on the product instance.

product.sayPrice()
// Output: I cost $10

If you log Product.prototype and product.__proto__ you will notice that they are the same object. When JavaScript sees that sayPrice is not an attribute of product, it checks its __proto__ and finds the sayPrice method there.

Inheritance

Now suppose we wanted to define a Book object type that inherits from Product. In Java, we would extend the base class.

public class Book extends Product {
  int pages;

  public Book(int pages, double price) {
    super(price);
    this.pages = pages;
  }
}

In JavaScript, we would create a Book constructor, inside of which we call the Product constructor, passing this as the context.

function Book(pages, price) {
  Product.call(this, price)
  this.pages = pages
}

Now if we create a book with

let book = new Book(154, 10)

we will get an object that has both the price and pages attributes. However, if we try to call

book.sayPrice()

we will get a TypeError: book.sayPrice is not a function. This is because we haven't updated Book's prototype object. To fix this, we can do

Book.prototype = Object.create(Product.prototype)

This sets Book's prototype to an empty object whose prototype is Product.prototype. In other words,

Book.prototype.__proto__ === Product.prototype
// Output: true

We can now run

let book = new Book(154, 10)
book.sayPrice()
// Output: I cost 10

and JavaScript will find sayPrice on book.__proto__.__proto__.

There is one other thing I should mention. By default, every constructor's prototype is an object with one attribute, constructor, which is a reference to the constructor itself. You can check this by running

Product.prototype.constructor === Product
// Output: true

When we set Book.prototype = Object.create(Product.prototype), we overwrote Book's default prototype, so book.constructor === Product, which isn't correct. We can fix this by either adding the constructor property afterwards

Book.prototype = Object.create(Product.prototype)
Object.defineProperty(Book.prototype, 'constructor', { 
    value: Book, 
    enumerable: false,
    writable: true
})

or by replacing the Object.create line with Object.assign

Book.prototype = Object.assign(Book.prototype, Product.prototype)

Now Book.prototype.constructor === Book should be true.

What About JavaScript's `class` Keyword?

JavaScript does have a class keyword, but it's just syntactic sugar for what we did above. It allows you to create the constructor and set methods on the prototype all in one block. For example, we could create an equivalent Product type with

class Product {
  constructor(price) {
    this.price = price
  }
  sayPrice() {
    return `I cost $${this.price}`
  }
}

If you log Product.prototype, you'll see that it is an object with both constructor and sayPrice properties, just like we had before. We can also create the Book sub type with

class Book extends Product {
  constructor(pages, price) {
    super(price)
    this.pages = pages
  }
}

Defining Book this way will automatically set Book.prototype and ensure that book.constructor is correct.

Conclusion

Objects in JavaScript are a bit confusing at first since they are quite different than in most other languages. I encourage you to open the dev tools in your browser and play around with these examples to get a feel for them. I hope this helps you understand JavaScript a little better!

How to Serve a React Single-Page App with Django

Zach Taylor — Mon, 21 Sep 2020 16:58:19 +0000

TL;DR

This article has been updated for Django 4, React 18 and Webpack 5. You can download the finished code from my GitHub repository. Leave a star if you found it helpful!

Intro

This is a guide on setting up Django to serve a React single-page application. Going through this process really helped me understand Webpack and Babel better, so if Django + React isn't your stack, you might still learn something!

All the commands and file paths you'll see are relative to the project root unless otherwise specified. If you don't have a project already, you can create one with

$ pip install Django
$ django-admin startproject django_react_starter
$ cd django_react_starter
$ python manage.py migrate

Let's get to it.

Step 1 - Create a Front End App

The first thing you'll want to do is create a Django app for your front end. I called mine frontend.

$ python manage.py startapp frontend

Add your app to INSTALLED_APPS in your project's settings.py file.

INSTALLED_APPS = [
  "frontend",
  ...
]

Step 2 - Create the View

Now that your frontend app is created, you need to create the Django view that will serve the React app.

In your frontend folder, create a folder called templates, and inside that, create a folder called frontend. In frontend/templates/frontend/ create an index.html file and put the following inside it.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My Site</title>
</head>
<body>
  <div id="app"></div>
</body>
</html>

Pretty simple. This HTML file is the single page in your single-page application. The <div id="app"></div>is where you will render your React app.

Next, you need to wire up a view to your index page. In frontend/views.py add the following.

from django.shortcuts import render

def index(request):
  return render(request, "frontend/index.html")

All this function does is render the index.html page you just created.

Now you need to tell Django the url at which it will find your index.html page. In your project level urls.py, add the following to the bottom of your urlpatterns (and make sure to import include!)

from django.urls import include, path

urlpatterns = [
  ...,
  path("", include("frontend.urls"))
]

In your frontend folder, create a urls.py file and put the following in it.

from django.urls import path
from . import views

urlpatterns = [
  path("", views.index)
]

These two urls.py files tell Django to call your index view when someone visits the url /. Try running the server with

$ python manage.py runserver

Go to localhost:8000 in your browser and you should see a blank page with My Site on the tab.

Great! Now let's add React to your HTML page.

Step 3 - Set up React, Babel, and Webpack

From the root of your project, run npm init -y to create a package.json file. You'll need several packages for this setup. The first two are React itself and ReactDom.

$ npm install react react-dom

Once you have React and ReactDom installed, you'll need to get Babel and Webpack set up.

Babel

Let's start with Babel. To install Babel, run

$ npm install --save-dev @babel/core

If you don't already know, Babel is a JavaScript transpiler, which essentially means it lets you use things in your JavaScript code (like JSX) that the browser wouldn't understand natively.

By default, Babel does nothing. If you want Babel to transpile a specific thing in your JavaScript code, you need to install a plugin for it. Your project might need several plugins, so Babel also has this concept of presets, which are just collections of plugins. You will only need two presets for this setup: @babel/preset-env and @babel/preset-react.

$ npm install --save-dev @babel/preset-env @babel/preset-react

@babel/preset-env is a collection of plugins that allows you to use the latest JavaScript features even if your browser doesn't support them yet. @babel/preset-react is a collection of plugins that allows you to do React things in a nice way, like use JSX instead of nested calls to React.createElement.

Once you install the presets, you need to tell Babel to use them. Create a .babelrc file in the root of your project with the following content.

{
  "presets": ["@babel/preset-env", "@babel/preset-react"]
}

Webpack

Webpack is a tool that will take your codebase and all its dependencies and transform them into one or more bundles, or files, that can be executed in a browser. The way it works is pretty simple, in concept. You give Webpack a JavaScript file (the entry point), and it will recursively gather all the dependencies of that file (indicated with import or require statements) and combine them into one, larger, file.

If you're not used to JavaScript, it might not make sense why Webpack is needed. Historically, there was no way to import or require resources in JavaScript running in the browser. You either had to put all your JavaScript into one file or put it in several files along with a <script> tag for each in your HTML. That's fine if your web site doesn't have much JavaScript, but it quickly becomes messy and hard to maintain as the amount of JavaScript you have grows. Webpack allows you to separate your JavaScript code into reusable files and import or require what you need.

And Webpack isn't just for JavaScript. It also allows you to import JSON by default as well, and it can be configured to allow imports from .css, .sass, .hbs and more with loaders.

For this Webpack setup, you'll need several packages.

$ npm install --save-dev webpack webpack-cli webpack-bundle-tracker babel-loader css-loader style-loader clean-webpack-plugin

That's quite a few! Let's break it down:

webpack is... well, Webpack
webpack-cli allows you to run Webpack commands from the command line
webpack-bundle-tracker is a plugin that writes some stats about the bundle(s) to a JSON file.
babel-loader is a loader that tells Webpack to run Babel on the file before adding it to the bundle.
css-loader and style-loader are loaders that allow you to import .css files into your JavaScript
clean-webpack-plugin is a plugin that deletes old bundles from Webpack's output directory every time a new bundle is created.

Now create a file called webpack.config.js in the root of your project. This is where you'll configure Webpack to use the plugins and loaders we just installed.

const path = require('path')
const BundleTracker = require('webpack-bundle-tracker')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')

module.exports = {
  entry: {
    frontend: './frontend/src/index.js',
  },
  output: {
    path: path.resolve('./frontend/static/frontend/'),
    filename: '[name]-[hash].js',
    publicPath: 'static/frontend/',
  },
  plugins: [
    new CleanWebpackPlugin(),
    new BundleTracker({
      path: __dirname,
      filename: './webpack-stats.json',
    }),
  ],
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: ['babel-loader'],
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
}

Let's break it down:

entry tells Webpack where to start gathering your code
output is where Webpack will put the finished bundle.
plugins tells Webpack which plugins to use
module is where you configure your loaders. Each rule tells Webpack that whenever it comes across a file that matches the test regex, it should use the specified loaders to process it.

Now that Webpack is set up, you'll want to add a couple scripts to your package.json to run Webpack.

{
  ...,
  "scripts": {
    ...,
    "dev": "webpack --config webpack.config.js --watch --mode development",
    "build": "webpack --config webpack.config.js --mode production"
  }
}

These scripts allow you to create a development bundle with npm run dev and a production bundle with npm run build.

Step 4 - Add the Bundle to your HTML

Now that you have a process to create a JavaScript bundle, you need to include the bundle in your HTML page. To do that, you'll need to install one more package.

$ pip install django-webpack-loader

This package allows Django to use the stats produced by webpack-bundle-tracker to load the correct bundle in your HTML page. In your settings.py file, add the following configuration.

import os

...

INSTALLED_APPS = [
  "webpack_loader",
  ...
]

...

WEBPACK_LOADER = {
  "DEFAULT": {
    "BUNDLE_DIR_NAME": "frontend/",
    "STATS_FILE": os.path.join(BASE_DIR, "webpack-stats.json")
  }
}

Then in your frontend/templates/frontend/index.html file, add a template tag to load the bundle into your page.

<!DOCTYPE html>
+ {% load render_bundle from webpack_loader %}
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My Site</title>
</head>
<body>
  <div id="app"></div>
+ {% render_bundle 'frontend' %}
</body>
</html>

Step 5 - Create Your React App

We now have all the pieces in place for you to begin writing your React application! In your frontend folder, create a folder called src, and inside that, create a file called App.js with the following content.

import React from 'react'

const App = () => {
  return (
    <div>Hello, World!</div>
  )
}

export default App

In your frontend/src folder, create another file called index.js with the following.

import React from "react";
import { createRoot } from "react-dom/client";
import App from "./App";

const root = createRoot(document.getElementById("app"));
root.render(<App />);

In the terminal navigate to your project and run

$ npm run dev

In another terminal window or tab, navigate to your project and run

$ python manage.py runserver

The order you run these two commands is important. Make sure you do npm run dev first.

Navigate to localhost:8000 in your browser and you should see Hello, World! printed on the screen. Awesome! You've successfully set up Django to serve a React single-page application. You can view or download the finished code on my GitHub repository.

Going through the process of setting this up was so helpful to me in understanding Webpack and Babel. I hope you found it enlightening as well!

DEV Community: Zach Taylor

K-Means Clustering

A Phoenix LiveView is Just a Process

Some Thoughts on Server State in Remix

Progressive Enhancement in Django vs Remix

An Intro to HTML Forms

What is a form?

The method Parameter

Customize the POST body with enctype

Other HTTP methods

The action Parameter

Conclusion

Stable Forms in Remix

Case 1 - The Native HTML <form>

Case 2 - Remix's Enhanced <Form>

Building a Simple Search UI with Remix

The Route

The Search Bar

Upgrading to <Form>

Persisting Across Route Transitions

Conclusion

Improving Your React Code - Custom Hooks

An Example

This is nothing new

Better Dev Tools

How much?

Conclusion

How to Add Custom Fonts to a GatsbyJS Site

pyp - A pip wrapper that writes requirements for you

Inheritance in JavaScript

Prototype Objects

An Example

Inheritance

What About JavaScript's class Keyword?

Conclusion

How to Serve a React Single-Page App with Django

TL;DR

Intro

Step 1 - Create a Front End App

Step 2 - Create the View

Step 3 - Set up React, Babel, and Webpack

Babel

Webpack

Step 4 - Add the Bundle to your HTML

Step 5 - Create Your React App

The `method` Parameter

Customize the POST body with `enctype`

The `action` Parameter

Case 1 - The Native HTML `<form>`

Case 2 - Remix's Enhanced `<Form>`

Upgrading to `<Form>`

What About JavaScript's `class` Keyword?