Developer News

Multiplayer Tic Tac Toe with GraphQL

Css Tricks - Fri, 08/23/2019 - 4:35am

GraphQL is a query language for APIs that is very empowering for front-end developers. As the GraphQL site explains it, you describe your data, ask for what you want, and get predictable results.

If you haven’t worked with it before, GraphQL might be a little confusing to grok at first glance. So, let’s build a multiplayer tic-tac-toe game using it in order to demonstrate how it’s used and what we can do with it.

First thing we need is a backend for our APIs. We’re going to use Hasura GraphQL Engine along with a custom GraphQL server for this tutorial. We’ll look at the queries and mutations that the client-side needs to build the game. You can implement this kind of thing in whatever framework you wish, but we’re going with use React and Apollo for this tutorial.

Here’s what we’re making:

GitHub Repo

A brief GraphQL primer

GraphQL is a query language for APIs; a language with a syntax that defines a way to fetch data from the server. It works with any kind of API that is backed by a strong system that makes your codebase resilient. Some of the primary characteristics of GraphQL are:

  • The client can ask the server for what queries it supports (check out introspection for more).
  • The client must ask the server for exactly what it wants. It can't ask for something like a wildcard (*) but rather exact fields. For example, to get a user's ID and name, the GraphQL query would be something like: query { user { id name } }
  • Every query is made to a single endpoint and every request is a POST request.
  • Given a query, the structure of the response is enforced. For example, for the above query to get the id and name of a user object, a successful response would be something like: { "data": { "user": { "id": "AUTH:482919", "name": "Jon Doe" } } }

This series of articles is a great place to start if you want to know more about GraphQL.

Why are we using GraphQL, anyway?

We just discussed how GraphQL demands that the client must ask the server for exactly what it wants. That means there is no unnecessary data retrieved from the server, like in case of REST where you would receive a huge response even when you need one field. Getting what new need and only what we need optimizes responses so that they’re speedy and predictable.

The client can ask the server for its schema via introspection. This schema can be used to build queries dynamically using an API explorer like GraphiQL. It also enables linting and auto-completing because every query can be built with and cross-checked against the GraphQL schema. As a front-end developer, this greatly enhances the DX as there is much less human error involved.

Since there is a single endpoint and every request is a POST request, GraphQL can avoid a lot of boilerplate since it doesn't have to track endpoints, request payloads and response types. Response caching is much easier because every query response can be expected to be of a certain structure.

Furthermore, GraphQL has a well-defined spec for implementing real-time subscriptions. You do not have to come up with your own implementation details for building real-time servers. Build a server that complies with GraphQL’s real-time spec and any client can start consuming the real-time GraphQL APIs with ease.

GraphQL Terminology

I will be using some GraphQL terms in this post, so it’s worth covering a few of them here in advance.

  • Query: A GraphQL query is one that simply fetches data from the server.
  • Mutation: This is a GraphQL query that changes something on the server and fetches some data.
  • Subscription: This is a GraphQL query that subscribes the client to some changes on the server.
  • Query variables: These allow us to add parameters to a GraphQL query.
Getting back to the backend

Now that we have a cursory understanding of GraphQL, let’s start with modeling a backend. Our GraphQL backend would be a combination of Hasura GraphQL Engine and a custom GraphQL server. We will not go into the subtleties of code in this case.

Since Tic Tac Toe is a multiplayer game, there is a need to store state in the database. We will use Postgres as our database and Hasura GraphQL Engine as a GraphQL server that allows us to CRUD the data in Postgres over GraphQL.

Apart from CRUD on the database, we would also want to run some custom logic in the form of GraphQL mutations. We will use a custom GraphQL server for that.

Hasura describes itself quite nicely in its README file:

GraphQL Engine is a blazing-fast GraphQL server that gives you instant, realtime GraphQL APIs over Postgres, with webhook triggers on database events, and remote schemas for business logic.

Going a little deeper, Hasura GraphQL Engine is an open-source server that sits on top of a Postgres database and allows you to CRUD the data over real-time GraphQL. It works with both new and existing Postgres databases. It also has an access control layer that you can integrate with any auth provider. In this post though, we will not implement auth for the sake of brevity.

Let’s start by deploying an instance of Hasura GraphQL Engine to Heroku's free tier that comes with a fresh Postgres database. Go ahead, do it; it is free and you do not need to enter your credit card details :)

Once you deploy, you will land up on the Hasura console which is the admin UI to manage your backend. Note that the URL you are at, is your GraphQL Engine URL. Lets start with creating our required tables.


A user table will store our users. To create the table, go to the "Data" tab on top and click on the "Create Table" button.

This table has an id column which is the unique identifier of each user and a name column that stores the user’s name.


The board table will store the game boards where all the action happens. We’ll spin up a new board for each game that starts.

Lets look at the columns of this table:

  • id: A unique UUID for each board that is auto generated
  • user_1_id: The user_id of the first user. This user by default plays X in the game
  • user_2_id: The user_id of the second user. This user by default plays O.
  • winner: This is a text field that is set to X or O once the winner has been decided.
  • turn: This is a text field that can be X or O and it stores the current turn. It starts with X.

Since user_1_id and user_2_id store the user IDs, let’s add a constraint on the board table that ensures user_1_id and user_2_id to be present in table user.

Go to the "Modify" tab in the Hasura board table and add the foreign keys.

Adding the foreign key on user_1_id. We’ll need to add a new foreign key on user_2_id as well.

Now, based on these relationships, we need to create a connection between these tables so that we can query the user information while querying the board.

Go to the "Relationships" tab in Hasura and create relationships called user1 and user2 for user_1_id and user_2_id based suggested relations.


Finally, we need a move table that stores the moves made by users on a board.

Let’s look at the columns:

  • id: The unique identifier of each move that is auto generated
  • user_id: The ID of the user that made the move
  • board_id: The ID of the board that the move was made on
  • position: The position where the move was made (i.e. 1-9)

Since user_id and board_id are foreign keys to user and board table, respectively. We must create these foreign key constraints just like we did above. Next, create the relationships as user for the foreign key on user_id and board for the foreign key on board_id. Then, we’ll go back to the board table's "Relationship" tab and create the suggested relationship to move table. Call it moves.

We need a custom server

Apart from storing data in the database, we also want to perform custom logic. The logic? Whenever a user makes a move, the move must be validated, made before the turn must is switched.

In order to do that, we must run an SQL transaction on the database. I have written a GraphQL server that does exactly that that I’ve deployed on Glitch.

Now we have two GraphQL servers. But GraphQL spec enforces that there must be only one endpoint. For this purpose, Hasura supports remote schemas — i.e. you can provide an external GraphQL endpoint to Hasura and it will merge this GraphQL server with itself and serve the combined schema under a single endpoint. Let’s add this custom GraphQL server to our Hasura Engine instance:

  1. Fork the GraphQL server.
  2. Add an environment variable that is the connection to your Postgres database. To do that, go to, choose your app, go to "Settings" and reveal config vars.

A few more steps from there:

  1. Copy the value for the DATABASE_URL.
  2. Go to the GraphQL server you forked and paste that value in the .env file (POSTGRES_CONNECTION_STRING=<value>).
  3. Click on the "Show Live" button on top and copy the opened URL.

We’ll add this URL to GraphQL engine by adding it as a remote schema. Go to the "Remote Schemas" tab on top and click on the "Add" option.

We are done with setting up our backend!

Let’s work on the front end

I will not be going into the details of front-end implementation since y’all would choose to implement it in the framework of your choice. I’ll go ahead and provide all the required queries and mutations that you would need to build the game. Using these with the front-end framework of your choice will allow you to build a fully functional multiplayer Tic Tac Toe.


Apollo Client is the go-to library for client-side GraphQL. They have awesome abstractions for React, Vue, Angular, iOS, Android etc. It helps you save a lot of boilerplate and the DX is smooth. You might want to consider using Apollo client over doing everything from scratch.

Let’s discuss the queries and mutations that the client would need for this game.

Insert user

In the app that I built, I generated a random username for each user and inserted this name into the database whenever they open the app. I also stored the name and generated a user ID in local storage so that the same user does not have different usernames. The mutation I used is:

mutation ($name:String) { insert_user ( objects: { name: $name } ) { returning { id } } }

This mutation inserts an entry into the user table and returns the generated id. If you observe the mutation closely, it uses $name. This is called the query variable. When you send this mutation to the server along with the variables { "name": "bazooka"}, the GraphQL server would replace $name from the query variables, which in this case would be "bazooka."

If you wish, you can implement auth and insert into this table with the username or the nickname.

Load all boards

To load all the boards, we run a GraphQL subscription:

subscription { board ( where: { _and: { winner: { _is_null: true }, user_2_id: { _is_null: true } } } order_by: { created_at: asc } ) { id user1 { id name } user_2_id created_at winner } }

This subscription is a live query that returns the id, user1 along with their id and name (from the relationship), user_2_id, winner and created_at. We have set a where filter which fetches us only the boards without a valid winner and where user_2_id is null which means the board is is open for a player to join. Finally, we order these boards by their created_at timestamp.

Creating a board

Users can create boards for other people to join. To do that, they have to insert an entry into the boards table.

mutation ($user_id: Int) { insert_board ( objects: [{ user_1_id: $user_id, turn: "x", }] ) { returning { id } } } Joining a board

To join a board, a user needs to update the user_2_id of the board with their own user_id. The mutation looks like:

mutation ($user_id: Int, $board_id: uuid!) { update_board ( _set: { user_2_id: $user_id }, where: { _and: { id: { _eq: $board_id }, user_2_id: { _is_null: true }, user_1_id: { _neq: $user_id } } } ) { affected_rows returning { id } } }

In the above GraphQL mutation, we are setting the user_2_id of a board to a user_id. We have also added additional checks such that this action succeeds only if the joining player is not the creator and the board is not already full. After the mutation, we ask for the number of affected rows.

In my app, after joining a board, I would redirect users to /play?board_id=<board_id>.

Subscribing to the board

When both users are in game, we need real-time updates about the moves of each player. So we must subscribe to the given board that is being played on and also the moves (through the relationship).

subscription($board_id: uuid!) { board: board_by_pk (id: $board_id) { id moves (order_by: { id: desc}) { id position user { id name } user_id } user1 { id name } user2 { id name } turn winner } }

The above query subscribes the client to the board that is being played. Whenever a new move is played, the client will be updated with it.

Making a move

To make a move, we will be using the make_move mutation from our custom GraphQL server.

mutation ( $board_id: String!, $position: Int!, $user_id: Int! ) { make_move ( board_id: $board_id, position: $position, user_id: $user_id ) { success } }

This mutation takes a board_id, position and user_id from query variables. It validates the move, makes the move and also switches the turn. In the end, it returns whether this transaction was successful or not.

Tic Tac Whoa!

And now you have a working game of Tic Tac Toe! You can implement any real-time multiplayer game with GraphQL subscriptions using the concepts we covered. Let me know if you have any questions and I would be happy to answer.

The post Multiplayer Tic Tac Toe with GraphQL appeared first on CSS-Tricks.

Weekly Platform News: Improving UX on Slow Connections, a Tip for Writing Alt Text and a Polyfill for the HTML loading attribute

Css Tricks - Thu, 08/22/2019 - 1:13pm

In this week's roundup, how to determine a slow connection, what we should put into alt text for images, and a new polyfill for the HTML loading attribute, plus more.

Detecting users on slow connections

Algolia is using the Network Information API (see the API’s Chrome status page) to detect users on slow connections — about 9% of their users — and make the following adjustments to ensure a good user experience:

  • increase the request timeout when the user performs a search query (a static timeout can cause a false positive for users on slow connections)
  • show a notification to the user while they’re waiting for search results (e.g., "You are on a slow connection. This might take a while.")
  • request fewer search results to decrease the total response size
  • debounce queries (e.g., don’t send queries at every keystroke)
navigator.connection.addEventListener("change", () => { // effective round-trip time estimate in ms let rtt = navigator.connection.rtt; // effective connection type let effectiveType = navigator.connection.effectiveType; if (rtt > 500 || effectiveType.includes("2g")) { // slow connection } });

(via Jonas Badalic)

Alt text should communicate the main point

The key is to describe what you want your audience to get out of the image rather than a simple description of what the image is.

<!-- BEFORE --> <img alt="Graph showing the use of the phrase "Who you gonna call?" in popular media over time."> <!-- AFTER --> <img alt="Graph illustrating an 800% increase in the use of the phrase "Who you gonna call?" in popular media after the release of Ghostbusters on June 7th, 1984.">

(via Caitlin Cashin)

In other news...
  • There is a new polyfill for the HTML loading attribute that is used by wrapping the images and iframes that you want to lazy-load in <noscript> elements (via Maximilian Franzke).
  • WeChat, the Chinese multi-purpose app with over one billion monthly active users, hosts over one million "mini programs" that are built in a very similar fashion to web apps (essentially CSS and JavaScript) (via Thomas Steiner).
  • Microsoft has made 24 new (online) voices from 21 different languages available to the Speech Synthesis API in the preview version of Edge ("these voices are the most natural-sounding voices available today") (via Scott Low)

Read more news in my new, weekly Sunday issue. Visit for more information.

The post Weekly Platform News: Improving UX on Slow Connections, a Tip for Writing Alt Text and a Polyfill for the HTML loading attribute appeared first on CSS-Tricks.

Advice for Technical Writing

Css Tricks - Thu, 08/22/2019 - 6:30am

In advance of a recent podcast with the incredible technical writer and Smashing Magazine editor-in-chief Rachel Andrew, I gathered up a bunch of thoughts and references on the subject of technical writing. So many smart people have said a lot of smart things over the years that I thought I'd round up some of my favorite advice and sprinkle in my own experiences, as someone who has also done his fair share of technical writing and editing.

There is a much larger world of technical writing out there. My experience and interest is largely about web technology and blogging, so I'm coming at it from that angle and many of the people I quote throughout are in that same boat.

Picking something to write about

If you want to write for CSS-Tricks and you ask me what you should write about, I'm probably going to turn that question around on you. It's likely I don't know you well enough to pick the perfect topic for you. More importantly, what I really want you to write about is something that is personal and important to you. Articles rooted in recent excitement about a particular idea or technology always come out better than dictated assignments.

My best advice:

Write the article you wish you found when you googled something.

— Chris Coyier (@chriscoyier) October 30, 2017

That said, I do maintain a list of ideas specifically for this site. Any writing can be done on assignment and sometimes that elicits the spark needed for something great and on-target for the audience of a site.

Write at the moment of learning

The moment you learn something is the best time to write. It's fresh in your mind and you can remember what it was like before you understood it. You also understand what it takes to go from not knowing to knowing it. That's the journey you need to take people on.

If you don't have time, at least try to capture the vibe wherever you save your ideas. Don't just write down "dataset." Write down some quick notes like, "I didn't realize DOM elements had a .dataset property for getting and setting data attributes. I wonder if it's better to use that than getAttribute." That way, you'll be able to reload that realization in your brain when you revisit the idea.

What have you learned in just the last few days? I bet there is a blog post there. Manuel Matuzovic does an excellent job of putting this into practice with the "Today I Learned" (TIL) section of his blog.

Comparing technologies is an underused format

Here's some advice Rachel shared that I don't see taken advantage of nearly enough:

There is a sweet spot for writing technical posts and tutorials. Write for the professional who hasn't had time to learn that thing yet, and link it back to things they already know. For example explaining a modern JS technique to someone who knows jQuery.

— Rachel Andrew (@rachelandrew) February 20, 2019

Tell me about how this new framework relates to Backbone. Tell me how this CMS relates to WordPress. Tell me how some technology connects to another technology that is safe to assume is more widely understood.

Technology changes a lot, but what technology does doesn't change all that much.

Careful with that intro

The main comment I add on tutorials I review is to ask for an intro that describes what the tutorial is about. I'm 600 words in and still don't know what the tutorial is about and who it is for. #writing

— Rachel Andrew (@rachelandrew) January 5, 2018

Not getting to the point right at the top of technical articles is a dang epidemic. The start of a technical article is not the time to wax poetic or drop some cliché light philosophy like, "Web design sure has changed a lot." You don't have to be boring, but you do need to tell me what this article is going to get into and who it is for.

Brian Rinaldi says:

“Does the title make the article sound interesting?” If the title interests a reader, they’ll typically read the intro and decide, “Is it worth my time reading the whole thing?” A common mistake I see in a lot of technical posts is either too much introduction or, alternatively, far too little.

A single well-written paragraph can set the stage for a technical blog post.

Careful with the title, too

I remember a conversation from years ago with content strategist Erin Kissane where she strongly advised me to choose boring titles for everything. Not just the title of blog posts, but for everything, including the names of sections, tags, and even subheadings within posts.

Here's the thing with boring: it works. Boring isn't the right word either; it's clarity. The world is full of clickbait, and maybe that's effective in some genres, but technical blogging isn't one of them.

A nice clear blog post title: Getting Started with GraphQL, Phoenix, and React by Margaret Williford

A terrible version of the same: Build a web app with modern technologies in 30 minutes!

What's a web app? What technologies? What's modern about them? What's with the weird time limit?

SEO matters and Margaret's article is going to do a lot better in both the short and long term with that clear title.

The outro

Ben Halpern says that the next most important thing after the intro is:

[...] the last paragraph.

People don't read top-to-bottom the moment when they arrive, so there is a good chance it's the second paragraph people read. Personally, I find the beginning a lot more important than the ending, but there is a certain art to the ending as well.

A lot of people just <h2>Conclusion</h2> and write a few words about what was just went over. Honestly, I don't hate that. It falls into this time tested pattern:

  1. Tell 'em what you're gonna tell 'em
  2. Tell 'em
  3. Tell 'em what you told 'em

That helps your message sink in and brings things full circle. Technical blogging isn't terribly different from marketing in that sense. You're trying to get people to understand something and you're using whatever tricks you need to to get the job done. A little repetition is a classic trick.

Make it scannable

Brian Rinaldi says:

[...] the wall of text can be easily be made less intimidating and appear much more visually appealing through the use of visual elements that break it up. The easiest is to simply place section subheadings throughout your post.

I agree: subheadings are probably the easiest and most powerful trick for scannability.

Other methods:

  • Lists: Like what I'm doing right now! I didn't have to use a list. Paragraphs might have worked as well, but a list makes contextual sense here and is probably tricking some of you into reading this. Or at least scanning it and getting some key points in the process.
  • Images: Please make them relevant and contextual. Skip the funny GIF. Screenshots are often great in a technical context because they provide a visual to what might otherwise be a difficult concept to explain. I like Unsplash for thematic imagery, too, but you can do better than a random picture of trees, a woman drinking coffee, or a random rack of servers.
  • Illustrations: The abstract nature of an illustration is your friend. It tricks people into having a quick thought about what you are describing. They generally take a little work to pull off, but the pay-off for you and the reader can be huge.
  • Videos: You can't simply drop a 42-minute video in the middle of a blog post, but if you can make it clear that you are demonstrating something visual and the video is less than a minute, it can be a powerful choice. You've always got <video autoplay muted loop controls> as well to make it GIF-like.
  • Blocks of code: Technical blog posts are often about code. Don't avoid code, embrace it. I love how Dan Abramov sprinkles in code blocks in blog posts not so much to demonstrate syntax and setup, but to make points. I'm going to recommend Embedded Pens as well, because they're fully interactive demoes in addition to serving as code blocks.
  • Tables: Don't forget about tabular data! Presenting information (particularly data or definitions) in a table makes it more understandable than it would have been any other way.
  • Collapsing sections: The <details>/<summary> elements make quick work of collapsible content. If you've got a large section of content that is good to be there but doesn't need to be read by everyone, collapse it! Our reference guide of media queries for devices is a decent example of this in action.

Whatever you pick here, you should pick things that help enhance the points you're making even if in some ways it feels like trickery. It's trickery to help readability, and that's a good thing.

My favorite technique? A little bit of design. Use design principals like spacing, color, and alignment to help the readability of posts. We even go so far as to art direct some posts where design can enhance the central point being made.

The point here isn't to do away with walls of text altogether. Sometimes that's exactly what's needed because you're asking a reader to deeply read a passage that they otherwise wouldn't get what's needed from the content. However, more often than not, a post can strongly benefit from some healthy use of white space.

Use an active voice

I find this one a little tricky to wrap my head around, but Katy Decorah has a great presentation about technical writing that explains this point in great detail. It's kinda like using present tense and stating a point directly rather than passively.

Passive: "After the file is downloaded..."
Active: "After you download the file..."

Passive: "The request is processed by the server."
Active: "The server processes the request."

Here's another clear explanation with examples by Neal Whitman, read by Mignon Fogarty (Grammar Girl):

The key point is made about a minute into the recording. There are lots of words to avoid

"Just" is a big one. Brad Frost:

“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources. “Just” is a dangerous word.

There are plenty of others to avoid, which which I've written about before. Read the comments in that last link. Long story short: there are lots of words that do more harm than good in technical writing, not only because they can come across as preachy, but because they usually don't help the sentences where they're used. Try taking "just" out of any sentence. The sentence will still make sense without it.

Simply Clearly Just Of course Everyone knows Easy However So Basically Turns out In order to Very Be mindful of your tone

Tone is concerned with how you say something in consideration of the context. For example, you wouldn't deliver bad news to someone with a happy tone. The way you express yourself ought to be aligned with the situation.

This is our tone goal on this site:

Friendly. Authoritative. Welcoming. We're all in this together. Flexible (nondogmatic about ideas). Thankful.

MailChimp has a very extensive guide to theirs.

It's worth pointing out that tone and voice are separate concepts. I like to think of voice as never changing (it's your personality which is a part of who you are) while tone changes to suit the context. In other words, you can have a professional voice while communicating in a friendly tone.

I don't think there is one true tone that is perfect for technical writing, but since the high-level goal of any technical writing is to help someone understand something complicated, you can use tone to help. A joke in the middle of a set of intricate steps is confusing. A bunch! of! excitement! about something might feel out of place or disingenuous, but being drab and lifeless is worse. I'd say if you're writing under your own name, let's feel a little bit of your personality as long as it's not at the cost of clarity. If you're writing under a brand, match what they have established whether it has been codified or not.

Careful about length

The general tendency in technical writing is to write too much rather than too little. Wade Christensen:

Whether trained by school assignments with word minimums or just uncritical, most of us write too much. Beyond approaching each draft with a ruthless cutting mentality, there are several ways to write short from draft one.

Word limits can help, even if they're self-imposed.

I heard from a fledgling editor recently who struggled with his writers submitting posts with high word counts, so he suggested they keep it to 1000-1500 as a guideline and that seemed effective. This post is roughly double the high end there, for comparison.

The real solution, if the resources are there, is ruthless editing.

I personally don't find that writing too long is the only issue. I've had just as many occurrences of writers going too short and not digging into the topic deep enough. I don't like focusing on the length; I like focusing on the clarity of the delivery and usefulness of the content itself.

Side note: Breaking up a post into multiple parts (as separate posts in a series) is not a solution for posts that are too long. In fact, it can exacerbate the problem. Do that only if the different parts are thematically different and can stand alone without the other parts.

Don't stop yourself from writing

There is an invisible force, built from fear, that keeps a lot of people away from technical blogging. "Meh, everybody already knows this," you might think. (They don't). "What if I'm wrong and someone calls me out?" (You aren't wrong if what you're doing is working for you.)

There can still be blockers even if you overcome those fears and start putting words to screen. Here's Max Böck:

There is a thing that happens to me while writing. I start with a fresh idea, excited to shape it into words. But as time passes, I lose confidence.

The trick for Max is not to wait too long and to ignore feelings holding you back:

I’ll publish something as soon as I feel confident that all the important points I want to get across are there. I try to ignore the voice screaming “it’s not ready” just for long enough to push it online.

Jeremy Keith goes so far to say we shouldn't even keep drafts:

I think keeping drafts can be counterproductive. The problem is that, once something is a draft rather than a blog post, it’s likely to stay a draft and never become a blog post. And the longer something stays in draft, the less likely it is to ever see the light of day.

The chances that your writing helps someone is pretty high! Matthias Ott:

Even the smallest post can help someone else out there.

Think you're too inexperienced? You're probably not, but even if you were, a perspective from someone with less experience is still useful. Ali Spittel:

If you have a blog post that contains mostly correct information, or at least your interpretation of the topic, then you're experienced enough. There are lots of excellent posts out there from the perspective of newbies, and they're really important!

Fear is a real thing in writing and dealing with it can be debilitating. While it's primarily geared toward creative writing, The War of Art by Stephen Pressfield is a good read to help break through the fear.

There is no one perfect style

We each have our own unique perspectives and writing styles. One writing style might be more approachable to some, and can therefore help and benefit a large (or even small) number of people in ways you might not expect.

...says Sara Soueidan. She continues:

Just write.

Even if only one person learns something from your article, you’ll feel great, and that you’ve contributed — even if just a little bit — to this amazing community that we’re all constantly learning from.

Technical blog posts don't have to be devoid of creativity. You could create a wonderful technical blog post that is an annotated chat room conversation between two developers learning from each other. Or a blog post that is a series of videos that build on each other.

The more introductory, the higher the bar

The web is saturated with beginner-rated and surface-level blog posts. There's a sea of crash courses, 101s, and intros out there. You've gotta knock it out of the park if you want to stand out from the pack and be useful.

There is no particular change in tone necessarily for a beginner-focused post. You don't need to do the equivalent of talking slowly or talking down. You only need to be clear, and clarity is valuable to readers at any skill level, not to mention appreciated by them as well. A very advanced programmer can and will appreciate the clarity in a technical blog post even if it's something they already understand.

But the bar isn't that high in general

You don't need a decade of experience to write a blog post. I'd say it's closer to a day of experience, a desire to write, and having something to say. I think you'd be surprised at how little you need to do to make a blog post stand out and be read. Put in some effort, make clear points, focus on readability, and you will do well.

I hope the advice in this post helps!

Abstraction is helpful, but real-world examples are sometimes better

Christine writes:

It’s one thing to describe a high-level concept, and another to explain or illustrate how that concept applies to the real world. In technical writing, you’ll often be covering complex or hard-to-understand subjects, so it’s even more important to use a well-placed example or two to showcase why your topic matters, or how it relates to the real world.

I find myself pushing back on code that is too abstract more than I push back on code that is too focused on a real-world use case. I'd rather see ["Charles Adok", "Samantha Frederick"] than ["foo", "bar"] or [a, b] any day, but more importantly, what is then done with that data to make it feel like a relatable programming scenario.

But avoid real-world examples that come at the cost of clarity. If abstraction is useful to drive a complex point home without getting lost in the details, so be it.

Blogging opens doors

Everyone I've ever met who had ever actively blogged has said that blogging has had a positive impact on their career. Besides being a public demonstration of your ability to think and present ideas, it helps you understand things better. To teach is to learn.

I'd attribute my own blogging as the biggest contributor to any success I've had. Here's Khoi Vinh, a designer ten times more successful than I'll ever be:

It’s hard to overstate how important my blog has been, but if I were to try to distill it down into one word, it would be: “amplifier.”

You get better at what you do.

There is no way around it: practice makes you better. The expectations around practice are sometimes very clear and culturally ingrained. In order to get better at playing the piano, you take piano lessons and practice. We all know this. But people also say "Oh, I'm a terrible cook," as if cooking as a skill is somehow fundamentally different than playing the piano and doesn't require the same amount of learning and practice.

You get better at writing by writing more. That is, writing with stakes. Writing and then publicly publishing what you write such that people read it.

You can go to school for writing. You could get a writing coach. My thinking is nothing teaches better than writing often. Whatever it is you sink time into is what you end up getting good at. Is 10,000 hours a good framework for you? Go with it. Heck, I find even people that sit around watching a lot of TV end up being pretty damn good at watching TV.

Your voice alone < A story with context < Stories including others < Research and data along with stories including others

An article where you just say some stuff is OK. You're allowed to say stuff.

But you can do better.

An article where you tell a true story about how something worked for you is better. Context! Now we can better understand where you are coming from when you say your stuff. Plus everybody likes a story.

An article where you combine that with quoting other people's writing and stories is even better. Now you're painting a larger picture and helping validate what you're saying. Context and flavor!

An article where you combine all that with research and data is the best. Now you're being personal, acknowledging a world outside yourself, layering in context, and avoiding being too anecdotal. Kapow! Now you're writing!

Are you pitching?

Read what the site says about guest writing. Here's ours.

Not to scare you off, but 90% of submissions are garbage. Maybe 75% is outright spam and another 15% are people that clearly didn't read anything we had to say about guest posting and are way off base. I can usually tell from the quality of writing in the email itself if they'll be a good guest blogger.

I say things like that, and then feel compelled to remind you the bar isn't that high.

Are there any useful tools?

There probably is, but I don't wanna link you off to tools I can't vouch for. All I use is Dropbox Paper for collaborative writing because the sharing model is easy and allows for co-editing and commenting. Plus Grammarly because it catches a ton of mistakes as you go.


The post Advice for Technical Writing appeared first on CSS-Tricks.

Navbar Nudging on @keyframers

Css Tricks - Thu, 08/22/2019 - 4:18am

I got to be the featured guest over on The Keyframers the other day. We looked at a Dribbble shot by Björgvin Pétur Sigurjónsson and then slowly built it, taking some purposeful detours along the way to discuss various tech.

We start by considering doing it entirely in CSS, then go for some light JavaScript to alter some data attributes as state, then ultimately end up using flipping.

This is where we ended up:

See the Pen
Navbar Nudging w/ Chris Coyier | Three Person Collaborative Animation Tutorial | @keyframers 2.14.0
by @keyframers (@keyframers)
on CodePen.

The video:

(My audio goes from terrible to good at about 12 minutes.)

Other takes!

Some of our Animigos made their own fantastic versions of this animation!

➡️ @steeevg:
➡️ @mariod:

Have another solution in mind?
Give it a shot and share your results!

— the @keyframers (@keyframers) August 15, 2019

The post Navbar Nudging on @keyframers appeared first on CSS-Tricks.

Using requestAnimationFrame with React Hooks

Css Tricks - Wed, 08/21/2019 - 4:05am

Animating with requestAnimationFrame should be easy, but if you haven’t read React’s documentation thoroughly then you will probably run into a few things that might cause you a headache. Here are three gotcha moments I learned the hard way.

TLDR: Pass an empty array as a second parameter for useEffect to avoid it running more than once and pass a function to your state’s setter function to make sure you always have the correct state. Also, use useRef for storing things like the timestamp and the request’s ID.

useRef is not only for DOM references

There are three ways to store variables within functional components:

  1. We can define a simple const or let whose value will always be reinitialized with every component re-rendering.
  2. We can use useState whose value persists across re-renderings, and if you change it, it will also trigger re-rendering.
  3. We can use useRef.

The useRef hook is primarily used to access the DOM, but it’s more than that. It is a mutable object that persists a value across multiple re-renderings. It is really similar to the useState hook except you read and write its value through its .current property, and changing its value won’t re-render the component.

For instance, the example below will always show 5 even if the component is re-rendered by its parent.

function Component() { let variable = 5; setTimeout(() => { variable = variable + 3; }, 100) return <div>{variable}</div> }

...whereas this one will keep increasing the number by three and keeps re-rendering even if the parent does not change.

function Component() { const [variable, setVariable] = React.useState(5); setTimeout(() => { setVariable(variable + 3); }, 100) return <div>{variable}</div> }

And finally, this one returns five and won’t re-render. However, if the parent triggers a re-render then it will have an increased value every time (assuming the re-render happened after 100 milliseconds).

function Component() { const variable = React.useRef(5); setTimeout(() => { variable.current = variable.current + 3; }, 100) return <div>{variable.current}</div> }

If we have mutable values that we want to remember at the next or later renders and we don’t want them to trigger a re-render when they change, then we should use useRef. In our case, we will need the ever-changing request animation frame ID at cleanup, and if we animate based on the the time passed between cycles, then we need to remember the previous animation’s timestamp. These two variables should be stored as refs.

The side effects of useEffect

We can use the useEffect hook to initialize and cleanup our requests, though we want to make sure it only runs once; otherwise it’s going to end up creating, canceling and re-creating the animation frame request at every render. Here’s a working, but bad example:

function App() { const [state, setState] = React.useState(0) const requestRef = React.useRef() const animate = time => { // Change the state according to the animation requestRef.current = requestAnimationFrame(animate); } // DON’T DO THIS React.useEffect(() => { requestRef.current = requestAnimationFrame(animate); return () => cancelAnimationFrame(requestRef.current); }); return <div>{state}</div>; }

Why is it bad? If you run this, the useEffect will trigger the animate function that will both change the state and request a new animation frame. It sounds good, except that the state change will re-render the component by running the whole function again including the useEffect hook that will first as a cleanup cancel the request made by the animate function in the previous cycle and then spin up a new request. This ultimately replaces the request made by the animate function and it's completely unnecessary. We could avoid this by not spinning up a new request in the animate function, but that still wouldn't be so nice. It would still leave us with an unnecessary cleanup every round and if the component re-renders for some other reason — like the parent re-renders it or some other state has changed — then the unnecessary cancelation and request re-creation would still happen. It is a better pattern to only initialize requests once, keep them spinning by the animate function and then cleanup once when the component unmounts.

To make sure the useEffect hook runs only once, we can pass an empty array as a second argument to it. Passing an empty array has a side-effect though, which avoids us from having the correct state during animation. The second argument is a list of changing values that the effect needs to react to. We don’t want to react to anything — we only want to initialize the animation — hence we have the empty array. But React will interpret this in a way that means this effect doesn’t have to be up to date with the state. And that includes the animate function because it was originally called from the effect. As a result, if we try to get the value of the state in the animate function, it will always be the initial value. If we want to change the state based on its previous value and the time passed, then it probably won’t work.

function App() { const [state, setState] = React.useState(0) const requestRef = React.useRef() const animate = time => { // The 'state' will always be the initial value here requestRef.current = requestAnimationFrame(animate); } React.useEffect(() => { requestRef.current = requestAnimationFrame(animate); return () => cancelAnimationFrame(requestRef.current); }, []); // Make sure the effect runs only once return <div>{state}</div>; } The state’s setter function also accepts a function

There’s a way to use our latest state even if the useEffect hook locked our state to its initial value. The setter function of the useState hook can also accept a function. So instead of passing a value based on the current state as you probably would do most of the time:

setState(state + delta)

... you can also pass on a function that receives the previous value as a parameter. And, yes, that’s going to return the correct value even in our situation:

setState(prevState => prevState + delta) Putting it all together

Here’s a simple example to wrap things up. We’re going to put all of the above together to create a counter that counts up to 100 then restarts from the beginning. Technical variables that we want to persist and mutate without re-rendering the whole component are stored with useRef. We made sure useEffect only runs once by passing an empty array as its second parameter. And we mutate the state by passing on a function to the setter of useState to make sure we always have the correct state.

See the Pen
Using requestAnimationFrame with React hooks
by Hunor Marton Borbely (@HunorMarton)
on CodePen.

Update: Taking the extra mile with a custom Hook

Once the basics are clear we can also go meta with Hooks, by extracting most of our logic into a custom Hook. This will have two benefits:

  1. It greatly simplifies our component, hiding technical variables that are related to the animation, but not to our main logic
  2. Custom Hooks are reusable. If you need an animation in another component you can simply use it there as well

Custom Hooks might sound like an advanced topic at first, but ultimately we just move a part of our code from our component to a function, then call that function in our component just like any other function. As a convention, a custom Hook's name should start with the use keyword and the rules of Hooks apply, but otherwise, they are just simple functions that we can customize with inputs and that might return something.

In our case to make a generic Hook for requestAnimationFrame we can pass on a callback that our custom Hook will call at every animation cycle. This way our main animation logic will stay in our component, but the component itself will be more focused.

See the Pen
Using requestAnimationFrame with custom React Hook
by Hunor Marton Borbely (@HunorMarton)
on CodePen.

The post Using requestAnimationFrame with React Hooks appeared first on CSS-Tricks.

Other Ways to SPAs

Css Tricks - Wed, 08/21/2019 - 4:04am

That rhymed lolz.

I mentioned on a podcast the other day that I sorta think WordPress should ship with Turbolinks. It's a rather simple premise:

  1. Build a server-rendered site.
  2. Turbolinks intercepts clicks on same-origin links.
  3. It uses AJAX for the HTML of the new page and replaces the current page with the new one.

In other words, turning a server-rendered app into "Single Page App" (SPA) by way of adding this library.

Why bother? It can be a little quicker. Full page refreshes can feel slow compared to an SPA. Turbolinks is kinda "old" technology, but it's still perfectly useful. In fact, Starr Horne recently wrote a great blog post about migrating to it at Honeybadger:

Honeybadger isn't a single page app, and it probably won't ever be. SPAs just don't make sense for our technical requirements. Take a look:

  • Our app is mostly about displaying pages of static information.
  • We crunch a lot of data to generate a single error report page.
  • We have a very small team of four developers, and so we want to keep our codebase as small and simple as possible.

... There's an approach we've been using for years that lets us have our cake and eat it too ... and its big idea is that you can get SPA-like speed without all the JavaScript.

That's what I mean about WordPress. It's very good that it's server-rendered by default, but it could also benefit from SPA stuff with a simple approach like Turbolinks. You could always add it on your own though.

Just leaving your server-rendered site isn't a terrible thing. If you keep the pages light and resources cached, you're probably fine.

Chrome has started some new ideas:

I don't doubt this server-rendered but enhance-into-SPA is what has helped popularize approaches like Next and Gatsby.

I don't want to discount the power of a "real" SPA approach. The network is the main offender for slow websites, so if an app is architected to shoot across relatively tiny bits of data (rather relatively heavy huge chunks of HTML) and then calculate the smallest amount of the DOM it can re-render and do that, then that's pretty awesome. Well, that is, until the bottleneck becomes JavaScript itself.

It's just unfortunate that an SPA approach is often done at the cost of doing no server-side rendering at all. And similarly unfortunate is that the cost of "hydrating" a server-rendered app to become an SPA comes at the cost of tying up the main thread in JavaScript.

Damned if you do. Damned if you don't.

Fortunately, there is a spectrum of rendering choices for choosing an appropriate architecture.

The post Other Ways to SPAs appeared first on CSS-Tricks.

Getting Netlify Large Media Going

Css Tricks - Tue, 08/20/2019 - 11:51am

I just did this the other day so I figured I'd blog it up. There is a thing called Git Large File Storage (Git LFS). Here's the entire point of it: it keeps large files out of your repo directly. Say you have 500MB of images on your site and they kinda need to be in the repo so you can work with it locally. But that sucks because someone cloning the repo needs to download a ton of data. Git LFS is the answer.

Netlify has a product on top of Git LFS called Large Media. Here's the entire point of it: In addition to making it all easier to set up and providing a place to put those large files, once you have your files in there, you can URL query param based resizing on them, which is very useful. I'm all about letting computers do my image sizing for me.

You should probably just read the docs if you're getting started with this. But I ran into a few snags so I'm jotting them down here in case this ends up useful.

You gotta install stuff

I'm on a Mac, so these are the things I did. You'll need:

  1. Git LFS itself: brew install git-lfs
  2. Netlify CLI: npm install netlify-cli -g
  3. Netlify Large Media add-on for the CLI: netlify plugins:install netlify-lm-plugin and then netlify lm:install
"Link" the site

You literally have to auth on Netlify and that connects Netlify CLI to the site you're working on.

netlify link

It will create a .netlify/state.json file in your project like this:

{ "siteId": "xxx" } Run setup netlify lm:setup

This creates another file in your project at .lsfconfig:

[lfs] url =

You should commit them both.

"Track" all your images

You'll need to run more terminal commands to tell Netlify Large Media exactly which images should be on Git LFS. Say you have a bunch of PNGs and JPGs, you could run:

git lfs track "*.jpg" "*.png"

This was a minor gotcha for me. My project had mostly .jpeg files and I got confused why this wasn't picking them up. Notice the slightly different file extension (ughadgk).

This will make yet another file on your project called .gitattributes. In my case:

*.jpg filter=lfs diff=lfs merge=lfs -text *.png filter=lfs diff=lfs merge=lfs -text *.jpeg filter=lfs diff=lfs merge=lfs -text

This time, when you push, all the images will upload to the Netlify Large Media storage service. It might be an extra-slow seeming push depending on how much you're uploading.

My main gotcha was at this point. This last push would just spin and spin for me and my Git client and eventually fail. Turns out I needed to install the netlify-credential-helper. It worked fine after I did that.

And for the record, it's not just images that can be handled this way, it's any large file. I believe they are called "binary" files and are what Git isn't particularly good at handling.

Check out your repo, the images are just pointers now Git repo where a JPG file isn't actually an image, but a small text pointer. And the best part

To resize the image on-the-fly to the size I want, I can do it through URL params:

<img src="slides/Oops.003.jpeg?nf_resize=fit&w=1000" alt="Screenshots of CSS-Tricks and CodePen homepages" />

Which is superpowered by a responsive images syntax. For example...

<img srcset="img.jpg?nf_resize=fit&w=320 320w, img.jpg?nf_resize=fit&w=480 480w, img.jpg?nf_resize=fit&w=800 800w" sizes="(max-width: 320px) 280px, (max-width: 480px) 440px, 800px" src="img.jpg?nf_resize=fit&w=800" alt="Elva dressed as a fairy">

The post Getting Netlify Large Media Going appeared first on CSS-Tricks.

Let’s Build a JAMstack E-Commerce Store with Netlify Functions

Css Tricks - Tue, 08/20/2019 - 4:41am

A lot of people are confused about what JAMstack is. The acronym stands for JavaScript, APIs, and Markup, but truly, JAMstack doesn’t have to include all three. What defines JAMstack is that it’s served without web servers. If you consider the history of computing, this type of abstraction isn’t unnatural; rather it’s the inevitable progression this industry has been moving towards.

So, if JAMstack tends to be static by definition, it can’t have dynamic functionality, server-side events, or use a JavaScript framework, right? Thankfully, not so. In this tutorial, we’ll set up a JAMstack e-commerce app and add some serverless functionality with Netlify Functions (which abstract AWS Lambda, and are super dope in my opinion).

I'll show more directly how the Nuxt/Vue part was set up in a follow-up post, but for now we're going to focus on the Stripe serverless function. I'll show you how I set this one up, and we'll even talk about how to connect to other static site generators such as Gatsby. Full disclosure, I work for Netlify, and am using their tools for this, it is possible to connect to Stripe with other services. I chose to work for Netlify in part because I enjoy some of the nice abstractions that their services offer.

This site and repo should get you started if you’d like to set something like this up yourself:

Demo Site

GitHub Repo Scaffold our app

The very first step is to set up our app. This one is built with Nuxt to create a Vue app, but you can replace these commands with your tech stack of choice:

yarn create nuxt-app hub create git add -A git commit -m “initial commit” git push -u origin master

I am using yarn, hub (which allows me to create repos from the command line) and Nuxt. You may need to install these tools locally or globally before proceeding.

With these few commands, following the prompts, we can set up an entirely new Nuxt project as well as the repo.

If we log into Netlify and authenticate, it will ask us to pick a repo:

I'll use yarn generate to create the project. With that, I can add in the site settings for Nuxt in the dist directory and hit feploy! That's all it takes to set up CI/CD and deploy the site! Now every time I push to the master branch, not only will I deploy, but I'll be given a unique link for that particular deploy as well. So awesome.

A basic serverless function with Netlify

So here's the exciting part, because the setup for this kind of functionality is so quick! If you’re unfamiliar with Serverless, you can think of it like the same JavaScript functions you know and love, but executed on the server. Serverless functions are event-driven logic and their pricing is extremely low (not just on Netlify, but industry-wide) and scales with your usage. And yes, we have to add the qualifier here: serverless still uses servers, but babysitting them is no longer your job. Let’s get started.

Our very basic function looks like this. I stored mine in a folder named functions, and just called it index.js. You can truly call the folder and function what you want.

// functions/index.js exports.handler = async (event, context) => { return { statusCode: 200, body: JSON.stringify({ message: "Hi there Tacos", event }) } }

We’ll also need to create a netlify.toml file at the root of the project and let it know which directory to find the function in, which in this case, is "functions."

// netlify.toml [build] functions = "functions"

If we push to master and go into the dashboard, you can see it pick up the function!

If you look at the endpoint listed above it’s stored here:

Really, for any site you give it, the URL will follow this pattern:

When we hit that endpoint, it provides us with the message we passed in, as well as all the event data we logged as well:

I love how few steps that is! This small bit of code gives us infinite power and capabilities for rich, dynamic functionality on our sites.

Hook up Stripe

Pairing with Stripe is extremely fun because it's easy to use, sophisticated, has great docs, and works well with serverless functions. I have other tutorials where I used Stripe because I enjoy using their service so much.

Here’s a bird’s eye view of the app we’ll be building:

First we’ll go to the Stripe dashboard and get our keys. For anyone totally scandalized right now, it's OK, these are testing keys. You can use them, too, but you’ll learn more if you set them up on your own. (It’s two clicks and I promise it’s not hard to follow along from here.)

We’ll install a package called dotenv which will help us store our key and test it locally. Then, we’ll store our Stripe secret key to a Stripe variable. (You can call it anything, but here I’ve called it STRIPE_SECRET_KEY, and that’s pretty much industry standard.)

yarn add dotenv require("dotenv").config() const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY)

In the Netlify dashboard, we’ll go to "Build & deploy," then "Environment" to add in Environment variables, where the STRIPE_SECRET_KEY is key, and the value will be the key that starts with sk.

We’ll also add in some headers so we don’t run into CORS issues. We’ll use these headers throughout the function we’re going to build.

const headers = { "Access-Control-Allow-Origin": "*", "Access-Control-Allow-Headers": "Content-Type" }

So, now we’ll create the functionality for talking to Stripe. We’ll make sure we’ll handle the cases that it’s not the HTTP method we’re expecting, and also that we’re getting the information we expect.

You can already see here, what data we’re going to be needing to send to stripe by what we check for. We’ll need the token, the total amount, and an idempotency key.

If you're unfamiliar with idempotency keys, they are unique values that are generated by a client and sent to an API along with a request in case the connection is disrupted. If the server receives a call that it realizes is a duplicate, it ignores the request and responds with a successful status code. Oh, and it's an impossible word to pronounce.

exports.handler = async (event, context) => { if (!event.body || event.httpMethod !== "POST") { return { statusCode: 400, headers, body: JSON.stringify({ status: "invalid http method" }) } } const data = JSON.parse(event.body) if (!data.stripeToken || !data.stripeAmt || !data.stripeIdempotency) { console.error("Required information is missing.") return { statusCode: 400, headers, body: JSON.stringify({ status: "missing information" }) } }

Now, we’ll kick off the Stripe payment processing! We’ll create a Stripe customer using the email and token, do a little logging, and then create the Stripe charge. We’ll specify the currency, amount, email, customer ID, and give a description while we're at it. Finally, we’ll provide the idempotency key (pronounced eye-dem-po-ten-see), and log that it was successful.

(While it's not shown here, we’ll also do some error handling.)

// stripe payment processing begins here try { await stripe.customers .create({ email: data.stripeEmail, source: data.stripeToken }) .then(customer => { console.log( `starting the charges, amt: ${data.stripeAmt}, email: ${data.stripeEmail}` ) return stripe.charges .create( { currency: "usd", amount: data.stripeAmt, receipt_email: data.stripeEmail, customer:, description: "Sample Charge" }, { idempotency_key: data.stripeIdempotency } ) .then(result => { console.log(`Charge created: ${result}`) }) }) Hook it up to Nuxt

If we look back at our application, you can see we have pages and components that live inside the pages. The Vuex store is like the brain of our application. It will hold the state of the app, and that's what will communicate with Stripe. However, we still need to communicate with our user via the client. We'll collect the credit card data in a component called AppCard.vue that will live on the cart page.

First, we'll install a package called vue-stripe-elements-plus, that gives us some Stripe form elements that allow us to collect credit card data, and even sets us up with a pay method that allows us to create tokens for stripe payment processing. We'll also add a library called uuid that will allow us to generate unique keys, which we'll use for the idempotency key.

yarn add vue-stripe-elements-plus uuid

The default setup they give us to work with vue-stripe-elements-plus looks like this:

<template> <div id='app'> <h1>Please give us your payment details:</h1> <card class='stripe-card' :class='{ complete }' stripe='pk_test_XXXXXXXXXXXXXXXXXXXXXXXX' :options='stripeOptions' @change='complete = $event.complete' /> <button class='pay-with-stripe' @click='pay' :disabled='!complete'>Pay with credit card</button> </div> </template> <script> import { stripeKey, stripeOptions } from './stripeConfig.json' import { Card, createToken } from 'vue-stripe-elements-plus' export default { data () { return { complete: false, stripeOptions: { // see for details } } }, components: { Card }, methods: { pay () { // createToken returns a Promise which resolves in a result object with // either a token or an error key. // See for the token object. // See for the error object. // More general createToken().then(data => console.log(data.token)) } } } </script>

So here's what we're going to do. We're going to update the form to store the customer email, and update the pay method to send that and the token or error key to the Vuex store. We'll dispatch an action to do so.

data() { return { ... stripeEmail: "" }; }, methods: { pay() { createToken().then(data => { const stripeData = { data, stripeEmail: this.stripeEmail }; this.$store.dispatch("postStripeFunction", stripeData); }); }, ...

That postStripeFunction action we dispatched looks like this:

// Vuex store export const actions = { async postStripeFunction({ getters, commit }, payload) { commit("updateCartUI", "loading") try { await axios .post( "", { stripeEmail: payload.stripeEmail, stripeAmt: Math.floor(getters.cartTotal * 100), //it expects the price in cents stripeToken: "tok_visa", //testing token, later we would use stripeIdempotency: uuidv1() //we use this library to create a unique id }, { headers: { "Content-Type": "application/json" } } ) .then(res => { if (res.status === 200) { commit("updateCartUI", "success") setTimeout(() => commit("clearCart"), 3000) …

We're going to update the UI state to loading while we're processing. Then we'll use axios to post to our function endpoint (the URL you saw earlier in the post when we set up our function). We'll send over the email, the amt, the token and the unique key that we built the function to expect.

Then if it was successful, we'll update the UI state to reflect that.

One last note I'll give is that I store the UI state in a string, rather than a boolean. I usually start it with something like "idle" and, in this case, I'll also have "loading," "success," and "failure." I don't use boolean states because I've rarely encountered a situation where UI state only has two states. When you work with booleans for this purpose, you tend to need to break it out into more and more states, and checking for all of them can get increasingly complicated.

As it stands, I can reflect changes in the UI on the cart page with legible conditionals, like this:

<section v-if="cartUIStatus === 'idle'"> <app-cart-display /> </section> <section v-else-if="cartUIStatus === 'loading'" class="loader"> <app-loader /> </section> <section v-else-if="cartUIStatus === 'success'" class="success"> <h2>Success!</h2> <p>Thank you for your purchase. You'll be receiving your items in 4 business days.</p> <p>Forgot something?</p> <button class="pay-with-stripe"> <nuxt-link exact to="/">Back to Home</nuxt-link> </button> </section> <section v-else-if="cartUIStatus === 'failure'"> <p>Oops, something went wrong. Redirecting you to your cart to try again.</p> </section>

And there you have it! We’re all set up and running to accept payments with stripe on a Nuxt, Vue site with a Netlify function, and it wasn’t even that complicated to set up!

Gatsby Applications

We used Nuxt in this instance but if you wanted to set up the same kind of functionality with something that uses React such as Gatsby, there's a plugin for that. (Everything is plugin in Gatsby. ☺️)

You would install it with this command:

yarn add gatsby-plugin-netlify-functions

...and add the plugin to your application like this:

plugins: [ { resolve: `gatsby-plugin-netlify-functions`, options: { functionsSrc: `${__dirname}/src/functions`, functionsOutput: `${__dirname}/functions`, }, }, ]

The serverless function used in this demo is straight up JavaScript, so it's also portable to React applications. There's a plugin to add the Stripe script to your Gatsby app (again, everything is a plugin). Fair warning: this adds the script to every page on the site. To collect the credit card information on the client, you would use React Stripe Elements, which is similar to the Vue one we used above.

Just make sure that you're collecting from the client and passing all the information the function is expecting:

  • The user email
  • The total amount, in cents
  • The token
  • The idempotency key
Demo Site

GitHub Repo

With such a low barrier to entry, you can see how you can make really dynamic experiences with JAMstack applications. It's amazing how much you can accomplish without any maintenance costs from servers. Stripe and Netlify Functions make setting up payment processing in a static application such a smooth developer experience!

The post Let’s Build a JAMstack E-Commerce Store with Netlify Functions appeared first on CSS-Tricks.

Lazy load embedded YouTube videos

Css Tricks - Tue, 08/20/2019 - 4:41am

This is a very clever idea via Arthur Corenzan. Rather than use the default YouTube embed, which adds a crapload of resources to a page whether the user plays the video or not, use the little tiny placeholder webpage that is just an image you can click that is linked to the YouTube embed.

It still behaves essentially exactly the same: click, play video in place.

The trick is rooted in srcdoc, a feature of <iframe> where you can put the entire contents of an HTML document in the attribute. It's like inline styling but an inline-entire-documenting sort of thing. I've used it in the past when I embedded MailChimp-created newsletters on this site. I'd save the email into the database as a complete HTML document, retrieve it as needed, and chuck it into an <iframe> with srcdoc.

Arthur credits Remy for a tweak to get it working in IE 11 and Adrian for some accessibility tweaks.

I also agree with Hugh in the comments of that post. Now that native lazy loading has dropped in Chrome (see our coverage) we might as well slap loading="lazy" on there too, as that will mean no requests at all if it renders out of viewport.

I'll embed a demo here too:

See the Pen
Lazy Loaded YouTube Video
by Chris Coyier (@chriscoyier)
on CodePen.

Direct Link to ArticlePermalink

The post Lazy load embedded YouTube videos appeared first on CSS-Tricks.

Using rel=”preconnect” to establish network connections early and increase performance

Css Tricks - Mon, 08/19/2019 - 3:05pm

Milica Mihajlija:

Adding rel=preconnect to a <link> informs the browser that your page intends to establish a connection to another domain, and that you'd like the process to start as soon as possible. Resources will load more quickly because the setup process has already been completed by the time the browser requests them.

The graphic in the post does a good job of making this an obviously good choice for performance:

Robin did a good job of rounding up information on all this type of stuff a few years back. Looks like the best practice right now is using these two:

<link rel="preconnect" href=""> <link rel="dns-prefetch" href="">

For all domains that aren't the main domain you're loading the document from.

A quick look at CSS-Tricks resources right now, I get:

That'd be 14 extra <link> tags in the first few packets of data on every request on this site. It sounds like a perf win, but I'd want to test that before no-brainer chucking it in there.

Andy Davies did some recent experimentation:

So what difference can preconnect make?

I used the HTTP Archive to find a couple of sites that use Cloudinary for their images, and tested them unchanged, and then with the preconnect script injected. Each test consisted of nine runs, using Chrome emulating a mobile device, and the Cable network profile.

There’s a noticeable visual improvement in the first site, with the main background image loading over half a second sooner (top) than on the unchanged site (bottom).

This stuff makes me think of (which just went v2), which is a fancy little script that preloads things based on interactions. It's now a browser extension (FasterChrome) that I've been trying out. I can't say I notice a huge difference, but I'm almost always on fast internet connections.

The post Using rel=”preconnect” to establish network connections early and increase performance appeared first on CSS-Tricks.

Bounce Element Around Viewport in CSS

Css Tricks - Mon, 08/19/2019 - 4:34am

Let's say you were gonna bounce an element all around a screen, sorta like an old school screensaver or Pong or something.

You'd probably be tracking the X location of the element, increasing or decreasing it in a time loop and — when the element reached the maximum or minimum value — it would reverse direction. Then do that same thing with the Y location and you've got the effect we're after. Simple enough with some JavaScript and math.

Here's The Coding Train explaining it clearly:

Here's a canvas implementation. It's Pong so it factors in paddles and is slightly more complicated, but the basic math is still there:

See the Pen
by Joseph Gutierrez (@DerBaumeister)
on CodePen.

But what if we wanted to do this purely in CSS? We could write @keyframes that move the transform or left/top properties... but what values would we use? If we're trying to bounce around the entire screen (viewport), we'd need to know the dimensions of the screen and then use those values. But we never know that exact size in CSS.

Or do we?

CSS has viewport units, which are based on the size of the entire viewport. Plus, we've got calc() and we presumably know the size of our own element.

That's the clever root of Scott Kellum's demo:

See the Pen
Codepen screensaver
by Scott Kellum (@scottkellum)
on CodePen.

The extra tricky part is breaking the X animation and the Y animation apart into two separate animations (one on a parent and one on a child) so that, when the direction reverses, it can happen independently and it looks more screensaver-like.

<div class="el-wrap x"> <div class="el y"></div> </div> :root { --width: 300px; --x-speed: 13s; --y-speed: 7s; --transition-speed: 2.2s; } .el { width: var(--width); height: var(--width); } .x { animation: x var(--x-speed) linear infinite alternate; } .y { animation: y var(--y-speed) linear infinite alternate; } @keyframes x { 100% { transform: translateX(calc(100vw - var(--width))); } } @keyframes y { 100% { transform: translateY(calc(100vh - var(--width))); } }

I stole that idea, and added some blobbiness and an extra element for this little demo:

See the Pen
Morphing Blogs with `border-radius`
by Chris Coyier (@chriscoyier)
on CodePen.

The post Bounce Element Around Viewport in CSS appeared first on CSS-Tricks.

Can you view print stylesheets applied directly in the browser?

Css Tricks - Mon, 08/19/2019 - 4:33am


Let's take a look at how to do it in different browsers. Although note the date of this blog post. This stuff tends to change over time, so if anything here is wrong, let us know and we can update it.

In Firefox...

It's a little button in DevTools. So easy!

  1. Open DevTools (Command+Option+i)
  2. Go to the “Inspector” tab
  3. Click the little page icon
In Chrome and Edge...

It's a little weirder, I think, but it's still a fairly easy thing to do in DevTools.

  • Open DevTools (Command+Option+i)
  • If you don't have the weird-special-bottom-area-thing, press the Escape key
  • Click the menu icon to choose tabs to open
  • Select the “Rendering” tab
  • Scroll to bottom of the “Rendering” tab options
  • Choose print from the options for Emulate CSS media
In Safari...

Safari has a little button a lot like Firefox, but it looks different.

  1. Open DevTools (Command+Option+i)
  2. Go to the “Inspector” tab
  3. Click the little page icon

The post Can you view print stylesheets applied directly in the browser? appeared first on CSS-Tricks.

Draggin’ and Droppin’ in React

Css Tricks - Fri, 08/16/2019 - 4:56am

The React ecosystem offers us a lot of libraries that all are focused on the interaction of drag and drop. We have react-dnd, react-beautiful-dnd, react-drag-n-drop and many more, but some of them require quite a lot of work to build even a simple drag and drop demo, and some do not provide you with more complex functionality (e.g. multiple drag and drop instances), and if they do, it becomes very complex.

This is where react-sortable-hoc comes into play.

&#x1f4a1; This tutorial requires basic knowledge of React library and React hooks.

This library has “HOC" in its name for a good reason. It provides higher-order components that extends a component with drag and drop functionality.

Let’s walk through an implementation of its functionalities.

Spinning up a project

For this tutorial we are going to build an app with funny GIFs (from Chris Gannon!) that can be dragged around the viewport.

GitHub Repo

Let's create a simple app and add drag-n-drop functionality to it. We're going to use create-react-app to spin up a new React project:

npx create-react-app your-project-name

Now let's change to the project directory and install react-sorting-hoc and array-move. The latter is needed to move items in an array to different positions.

cd your-project-name yarn add react-sortable-hoc array-move Adding styles, data and GIF component

For simplicity's sake, we are going to write all styles in our App.css file. You can overwrite styles you have there with the following ones:

.App { background: #1a1919; color: #fff; min-height: 100vh; padding: 25px; text-align: center; } .App h1 { font-size: 52px; margin: 0; } .App h2 { color: #f6c945; text-transform: uppercase; } .App img { cursor: grab; height: 180px; width: 240px; }

Let's create our state with GIFs. For this purpose we gonna use React’s built-in useState hook:

import React, { useState } from 'react';

Now add following before the return statement:

const [gifs, setGifs] = useState([ '', '', '', '', ]);

It's time to create our simple GIF component. Create a Gif.js file in the src directory and pass in the following code:

import React from 'react'; import PropTypes from 'prop-types'; const Gif = ({ gif }) => (<img src={gif} alt="gif" />) Gif.propTypes = { gif: PropTypes.string.isRequired, }; export default Gif;

We always try to follow the best practices while writing code; thus we also import PropTypes for type checking.

Import the Gif component and add it to the main App component. With a bit of clean up, it looks like this:

import React, { useState } from 'react'; import './App.css'; import Gif from './Gif'; const App = () => { const [gifs, setGifs] = useState([ '', '', '', '', ]); return ( <div className="App"> <h1>Drag those GIFs around</h1> <h2>Set 1</h2> {, i) => <Gif key={gif} gif={gif} />)} </div> ); } export default App;

Go to http://localhost:3000/ to see what the app looks like now:

A screenshot of react-sortable-hoc-article-app Onto the drag-n-drop stuff

Alright, it's time make our GIFs draggable! And droppable.

To start, we need two HOCs from react-sortable-hoc, and the arrayMove method from the array-move library to modify our new array after dragging happens. We want our GIFs to stay on their new positions, right? Well, that’s what this is going to allow us to do.

Let's import them:

import { sortableContainer, sortableElement } from 'react-sortable-hoc'; import arrayMove from 'array-move';

As you might have guessed, those components will be wrappers which will expose functionality needed for us.

  • sortableContainer is a container for our sortable elements.
  • sortableElement is a container for each single element we are rendering.

Let's do the following after all our imports:

const SortableGifsContainer = sortableContainer(({ children }) => <div className="gifs">{children}</div>); const SortableGif = sortableElement(({ gif }) => <Gif key={gif} gif={gif} />);

We've just created a container for our children elements that would be passed inside our SortableGifsContainer and also created wrapper for a single Gif component.
If it's a bit unclear to you, no worries — you will understand right after we implement it.

&#x1f4a1;Note: You need to wrap your children in a div or any other valid HTML element.

It's time to wrap our GIFs into the SortableGifsContainer and replace the Gif component with our newly created SortableGif:

<SortableGifsContainer axis="x" onSortEnd={onSortEnd}> {, i) => <SortableGif // don't forget to pass index prop with item index index={i} key={gif} gif={gif} /> )} </SortableGifsContainer>

It’s important to note that you need to pass the index prop to your sortable element so the library can differentiate items. It's similar to adding keys to the lists in React).

We add axis because our items are positioned horizontally and we want to drag them horizontally, while default is vertical dragging. In other words, we’re limiting dragging along the horizontal x-axis. As you can see we also add an onSortEnd function, which triggers every time we drag or sort our items around. There are, of course, a lot more events but you can find more info in the documentation which already does an excellent job of covering them.

Time to implement it! Add the following line above the return statement:

const onSortEnd = ({ oldIndex, newIndex }) => setGifs(arrayMove(gifs, oldIndex, newIndex));

I want to explain one more thing: our function received an old and new index of the item which was dragged and, of course, each time after we move items around we modify our initial array with the help of arrayMove.

Tada! Now you know how to implement drag-n-drop in your project. Now go and do it! &#x1f389; &#x1f389; &#x1f389;

What if we have multiple lists of items?

As you can see, the previous example was relatively simple. You basically wrap each of the items in a sortable HOC and wrap it around with sortableContainer and, bingo, you've got basic drag and drop.

But how will we do it with multiple lists? The good news is that react-sortable-hoc provides us with a collection prop so we can differentiate between lists.

First, we should add second array of GIFs:

const [newGifs, setNewGifs] = useState([ '', '', '', '', ]);

If you want to see them before we move next, add the following lines after the SortableGifsContainer closing tag:

{ => <Gif key={gif} gif={gif} />)}

Alright, time to replace it with a draggable version.

Implementation is the same as in first example besides one thing — we have added a collection prop to our SortableGif. Of course, you can come up with any name for the collection, just remember, we're gonna need it in for our onSortEnd function.

<h2>Set 2</h2> <SortableGifsContainer axis="x" onSortEnd={onSortEnd}> {, i) => <SortableGif index={i} key={gif} gif={gif} collection="newGifs" />)} </SortableGifsContainer>

Next we need to add the collection prop to our first list. I've chosen the name GIFs for the first list of items, but it's up to you!

Now we need to to change our onSortEnd function. Our function received old and new indexes, but we can also destructure a collection from it. Right, exactly the one we've added to our SortableGif.

So all we have to do now is write a JavaScript switch statement to check for the collection name and to modify the right array of GIFs on drag.

const onSortEnd = ({ oldIndex, newIndex, collection }) => { switch(collection) { case 'gifs': setGifs(arrayMove(gifs, oldIndex, newIndex)) break; case 'newGifs': setNewGifs(arrayMove(newGifs, oldIndex, newIndex)) break; default: break; } }

Time to check it out!

As you can see, we now have two separate lists of GIFs and we can drag and sort. Moreover, they are independent meaning items from different lists won't be mixed up.

Exactly what we wanted to do! Now you know how to create and handle drag and drop with multiple lists of items. Congratulations &#x1f389;

Hope you've enjoyed it as much as I did writing it! If you’d like to reference the complete code, it’s all up on GitHub here. If you have any questions, feel free to contact me via email.

The post Draggin’ and Droppin’ in React appeared first on CSS-Tricks.

Accessibility and web performance are not features, they’re the baseline

Css Tricks - Fri, 08/16/2019 - 4:51am

This week I’ve been brooding about web performance and accessibility. It all began when Ethan Marcotte made a lot of great notes about the accessibility issues that are common with AMP:

In the recordings above, I’m trying to navigate through the AMP Story. And as I do, VoiceOver describes a page that’s impossible to understand: the arrows to go back or forward are simply announced as “button”; most images are missing text equivalents, which is why the screen reader spells out each and every character of their filenames; and when a story’s content is visible on screen, it’s almost impossible to access. I’d like to say that this one AMP Story was an outlier, but each of the nine demos listed on the AMP Stories website sound just as incomprehensible in VoiceOver.

Ethan continues to argue that these issues are so common in AMP that accessibility must not be a priority at all:

Since the beginning, Google has insisted AMP is the best solution for the web’s performance problem. And Google’s used its market dominance to force publishers to adopt the framework, going so far as to suggest that AMP’s the only format you need to publish pages on the web. But we’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.

I’ve been thinking a lot about this lately — about how accessibility work is often seen as an additional feature that can be tacked onto a project later — rather than accessibility work being a core principle or standard of working on the web.

And I’ve seen this sentiment expressed time and time again, in the frameworks, on Twitter, in the design process, in the development process, and so much so that arguing about the importance of accessibility can get pretty exhausting. Because at some point we’re not arguing about the importance of accessibility but the importance of front-end development itself as a series of worthy skills to have. Skills that can’t be replaced.

Similarly, this post by Craig Mod, on why software should be lightning fast, had me thinking along the same lines:

I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.

Later in the piece, Mod describes fast software as being the very definition of good software and argues that every action on a computer — whether that’s a website or an app — should feel as if you’re moving without any latency whatsoever. And I couldn’t agree more; every loading screen and wait time is in some degree a mark of failure.

Alex Russell made a similar point not so long ago when he looked at the performance of mobile phones and examined how everyone experiences the web in a very different way:

The takeaway here is that you literally can't afford desktop or iPhone levels of JS if you're trying to make good web experiences for anyone but the world's richest users, and that likely means re-evaluating your toolchain.

I’m sort of a jerk when it comes to this stuff. I don’t think a website can be good until it’s fast. The kind of fast that takes your breath away. As fast as human thought, or even faster. And so my point here is that web performance isn’t something we should aspire to, it should be the standard. The status quo. The baseline that our work is judged by. It ought to be un-shippable until the thing is fast.

The good news is that it’s easier than ever to ship a website with these base requirements of unparalleled speed and accessibility! We have Page Speed Insights, and Web Page Test, not to mention the ability to have Lighthouse perform audits with every commit in GitHub automatically as we work. Ire Aderinokun showed us how to do this not so long ago by setting up a performance budget and learning how to stick to it.

The tools to make our websites fast and accessible are here but we’re not using them. And that’s what makes me mad.

While I’m on this rant — and before I get off my particularly high horse — I think it’s important to make note of Deb Chachra’s argument that “any sufficiently advanced negligence is indistinguishable from malice.” With that in mind, it’s not just bad software design and development if a website is slow. Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.

Instead we must start to see inaccessible and slow websites for what they are: a form of cruelty. And if we want to build a web that is truly a World Wide Web, a place for all and everyone, a web that is accessible and fast for as many people as possible, and one that will outlive us all, then first we must make our websites something else altogether; we must make them kind.

The post Accessibility and web performance are not features, they’re the baseline appeared first on CSS-Tricks.

Weekly Platform News: HTML Loading Attribute, the Main ARIA Specifications, and Moving from iFrame to Shadow DOM

Css Tricks - Thu, 08/15/2019 - 11:27am

In this week's roundup of platform news, Chrome introduces a new attribute for loading, accessibility specifications for web developers, and the BBC moves visualizations to the Shadow DOM.

Chrome ships the loading attribute

The HTML loading attribute for lazy-loading images and iframes is now supported in Chrome. You can add loading="lazy" to defer the loading of images and iframes that are below the viewport until the user scrolls near them.

Google suggests either treating this feature as a progressive enhancement or using it on top of your existing JavaScript-based lazy-loading solution.

This feature has not yet been added to the HTML Standard (but there is an open pull request), and multiple links to Google’s documentation are listed on its Chrome Status page.


Overview of ARIA specifications

The main accessibility specifications for web developers:

Name Description ARIA in HTML Defines which ARIA role, state, and property attributes are allowed on which HTML elements (the implicit ARIA semantics are defined here) Using ARIA Provides practical advice on how to use ARIA in HTML, with an emphasis on dynamic content and advanced UI controls (the “five rules of ARIA use” are defined here) ARIA (Accessible Rich Internet Applications) Defines the ARIA roles, states, and properties ARIA Authoring Practices Provides general guidelines on how to use ARIA to create accessible apps (includes ARIA implementation patterns for common widgets) HTML Accessibility API Mappings Defines how browsers map HTML elements and attributes to the operating system’s accessibility APIs WCAG (Web Content Accessibility Guidelines) Provides guidelines for making web content more accessible (success criteria for WCAG conformance are defined here)

Related: “Contributing to the ARIA Authoring Practices Guide" by Simon Pieters and Valerie Young

Shadow DOM on the BBC website

The BBC has moved from <iframe> to Shadow DOM for the embedded interactive visualizations on its website. This has resulted in significant improvements in load performance (“more than 25% faster”).

The available Shadow DOM polyfills didn’t reliably prevent styles from leaking across the Shadow DOM boundary, so they decided to instead fall back to <iframe> in browsers that don’t support Shadow DOM.

Shadow DOM [...] can deliver content in a similar way to iframes in terms of encapsulation but without the negative overheads [...] We want encapsulation of an element whose content will appear seamlessly as part of the page. Shadow DOM gives us that without any need for a custom element.

One major drawback of this new approach is that CSS media queries can no longer be used to conditionally apply styles based on the content’s width (since the content no longer loads in a separate, embedded document).

With iframes, media queries would give us the width of our content; with Shadow DOM, media queries give us the width of the device itself. This is a huge challenge for us. We now have no way of knowing how big our content is when it’s served.

(via Toby Cox)

In other news...
  • The next version of Chrome will introduce the Largest Contentful Paint performance metric; this new metric is a more accurate replacement for First Meaningful Paint, and it measures when the largest element is rendered in the viewport (usually, the largest image or paragraph of text) (via Phil Walton)
  • Microsoft has created a prototype of a new tool for viewing a web page’s DOM in 3D; this tool is now experimentally available in the preview version of Edge (via Edge DevTools)
  • Tracking prevention has been enabled by default in the preview versions of Edge; it is set to balanced by default, which “blocks malicious trackers and some third-party trackers” (via Techdows)

Read more news in my new, weekly Sunday issue. Visit for more information.

The post Weekly Platform News: HTML Loading Attribute, the Main ARIA Specifications, and Moving from iFrame to Shadow DOM appeared first on CSS-Tricks.

The Making of an Animated Favicon

Css Tricks - Thu, 08/15/2019 - 4:47am

It’s the first thing your eyes look for when you’re switching tabs.

That’s one way of explaining what a favicon is. The tab area is a much more precious screen real-estate than what most assume. If done right, besides being a label with icon, it can be the perfect billboard to represent what’s in or what’s happening on a web page.

The CSS-Tricks Favicon

Favicons are actually at their most useful when you’re not active on a tab. Here’s an example:

Imagine you’re backing up photos from your recent summer vacation to a cloud service. While they are uploading, you’ve opened a new tab to gather details about the places you went on vacation to later annotate those photos. One thing led to the other, and now you’re watching Casey Neistat on the seventh tab. But you can’t continue your YouTube marathon without the anxious intervals of checking back on the cloud service page to see if the photos have been uploaded.

It’s this type of situation where we can get creative! What if we could dynamically change the pixels in that favicon and display the upload progress? That’s exactly what we’ll do in this article.

In supported browsers, we can display a loading/progress animation as a favicon with the help of JavaScript, HTML <canvas> and some centuries-old geometry.

Jumping straight in, we’ll start with the easiest part: adding the icon and canvas elements to the HTML.

<head> <link rel="icon" type="image/png" href="" width=32px> </head> <body> <canvas width=32 height=32></canvas> </body>

In practical use, you would want to hide the <canvas> on the page, and one way of doing that is with the HTML hidden attribute.

<canvas hidden width=32 height=32></canvas>

I’m going to leave the <canvas> visible on the page for you to see both the favicon and canvas images animate together.

Both the favicon and the canvas are given a standard favicon size: 32 square pixels.

For demo purposes, in order to trigger the loading animation, I’m adding a button to the page which will start the animation when clicked. This also goes in the HTML:


Now let’s set up the JavaScript. First, a check for canvas support:

onload = ()=> { canvas = document.querySelector('canvas'), context = canvas.getContext('2d'); if (!!context) { /* if canvas is supported */ } };

Next, adding the button click event handler that will prompt the animation in the canvas.

button = document.querySelector('button'); button.addEventListener('click', function() { /* A variable to track the drawing intervals */ n = 0, /* Interval speed for the animation */ loadingInterval = setInterval(drawLoader, 60); });

drawLoader will be the function doing the drawing at intervals of 60 milliseconds each, but before we code it, I want to define the style of the lines of the square to be drawn. Let’s do a gradient.

/* Style of the lines of the square that'll be drawn */ let gradient = context.createLinearGradient(0, 0, 32, 32); gradient.addColorStop(0, '#c7f0fe'); gradient.addColorStop(1, '#56d3c9'); context.strokeStyle = gradient; context.lineWidth = 8;

In drawLoader, we’ll draw the lines percent-wise: during the first 25 intervals, the top line will be incrementally drawn; in second quarter, the right line will be drawn; and so forth.

The animation effect is achieved by erasing the <canvas> in each interval before redrawing the line(s) from previous interval a little longer.

During each interval, once the drawing is done in the canvas, it’s quickly translated to a PNG image to be assigned as the favicon.

function drawLoader() { with(context) { clearRect(0, 0, 32, 32); beginPath(); /* Up to 25% */ if (n<=25){ /* (0,0)-----(32,0) */ // code to draw the top line, incrementally } /* Between 25 to 50 percent */ else if(n>25 && n<=50){ /* (0,0)-----(32,0) | | (32,32) */ // code to draw the top and right lines. } /* Between 50 to 75 percent */ else if(n>50 && n<= 75){ /* (0,0)-----(32,0) | | (0,32)----(32,32) */ // code to draw the top, right and bottom lines. } /* Between 75 to 100 percent */ else if(n>75 && n<=100){ /* (0,0)-----(32,0) | | | | (0,32)----(32,32) */ // code to draw all four lines of the square. } stroke(); } // Convert the Canvas drawing to PNG and assign it to the favicon favicon.href = canvas.toDataURL('image/png'); /* When finished drawing */ if (n === 100) { clearInterval(loadingInterval); return; } // Increment the variable used to keep track of the drawing intervals n++; }

Now to the math and the code for drawing the lines.

Here’s how we incrementally draw the top line at each interval during the first 25 intervals:

n = current interval, x = x-coordinate of the line’s end point at a given interval. (y-coordinate of the end point is 0 and start point of the line is 0,0)

At the completion of all 25 intervals, the value of x is 32 (the size of the favicon and canvas.)


x/n = 32/25 x = (32/25) * n

The code to apply this math and draw the line is:

moveTo(0, 0); lineTo((32/25)*n, 0);

For the next 25 intervals (right line), we target the y coordinate similarly.

moveTo(0, 0); lineTo(32, 0); moveTo(32, 0); lineTo(32, (32/25)*(n-25));

And here’s the instruction to draw all four of the lines with the rest of the code.

function drawLoader() { with(context) { clearRect(0, 0, 32, 32); beginPath(); /* Up to 25% of the time assigned to draw */ if (n<=25){ /* (0,0)-----(32,0) */ moveTo(0, 0); lineTo((32/25)*n, 0); } /* Between 25 to 50 percent */ else if(n>25 && n<=50){ /* (0,0)-----(32,0) | | (32,32) */ moveTo(0, 0); lineTo(32, 0); moveTo(32, 0); lineTo(32, (32/25)*(n-25)); } /* Between 50 to 75 percent */ else if(n>50 && n<= 75){ /* (0,0)-----(32,0) | | (0,32)----(32,32) */ moveTo(0, 0); lineTo(32, 0); moveTo(32, 0); lineTo(32, 32); moveTo(32, 32); lineTo(-((32/25)*(n-75)), 32); } /* Between 75 to 100 percent */ else if(n>75 && n<=100){ /* (0,0)-----(32,0) | | | | (0,32)----(32,32) */ moveTo(0, 0); lineTo(32, 0); moveTo(32, 0); lineTo(32, 32); moveTo(32, 32); lineTo(0, 32); moveTo(0, 32); lineTo(0, -((32/25)*(n-100))); } stroke(); } // Convert the Canvas drawing to PNG and assign it to the favicon favicon.href = canvas.toDataURL('image/png'); /* When finished drawing */ if (n === 100) { clearInterval(loadingInterval); return; } // Increment the variable used to keep track of drawing intervals n++; }

That’s all! You can see and download the demo code from this GitHub repo. Bonus: if you’re looking for a circular loader, check out this repo.

You can use any shape you want, and if you use the fill attribute in the canvas drawing, that’ll give you a different effect.

The post The Making of an Animated Favicon appeared first on CSS-Tricks.

Front Conference in Zürich

Css Tricks - Thu, 08/15/2019 - 4:20am

(This is a sponsored post.)

I'm so excited to be heading to Zürich, Switzerland for Front Conference (Love that name and URL!). I've never been to Switzerland before, so I'm excited about that, but of course, the web nerd in me is excited to be at the conference with lots of fellow webfolk. Some old friends, but mostly new people I've never met before but admire their work. Yessssss.

I cracked open DevTools on their speaker page and re-arranged the layout so I could take some screenshots of the incredible lineup:

If you're able to make it, come! As you know I'm bullish on conferences and their ability to get you thinking and feeling more connected to the web design and development community.

I'll be there

I'll be opening the conference as the first talk on the first day (after the workshops on Wednesday). I've been thinking a lot about what has been happening to front-end development and what it is to be a front-end developer so I'll be talking about all that. I hope it's a nice broad start to a whole conference dedicated to the topic.

Can't go but want to watch it live?

Good idea! Perhaps you could schedule a bit of a brown bag at work?

Follow @frontzurich on Twitter and they'll be announcing how to watch the livestream the days of the conference (Thursday August 29th and Friday August 30th).

Want to see the talks from years past?

Their Vimeo profile has everything!

Here's one from Rachel last year:

Direct Link to ArticlePermalink

The post Front Conference in Zürich appeared first on CSS-Tricks.

Staggered CSS Transitions

Css Tricks - Wed, 08/14/2019 - 4:08am

Let's say you wanted to move an element on :hover for a fun visual effect.

@media (hover: hover) { .list--item { transition: 0.1s; transform: translateY(10px); } .list--item:hover, .list--item:focus { transform: translateY(0); } }

Cool cool. But what if you had several list items, and you wanted them all to move on hover, but each one offset with staggered timing?

The trick lies within transition-delay and applying a slightly different delay to each item. Let's select each list item individually and apply different delays. In this case, we'll select an internal span just for fun.

@media (hover: hover) { .list li a span { transform: translateY(100px); transition: 0.2s; } .list:hover span { transform: translateY(0); } .list li:nth-child(1) span { transition-delay: 0.0s; } .list li:nth-child(2) span { transition-delay: 0.05s; } .list li:nth-child(3) span { transition-delay: 0.1s; } .list li:nth-child(4) span { transition-delay: 0.15s; } .list li:nth-child(5) span { transition-delay: 0.2s; } .list li:nth-child(6) span { transition-delay: 0.25s; } }

See the Pen
Staggered Animations
by Chris Coyier (@chriscoyier)
on CodePen.

If you wanted to give yourself a little more programmatic control, you could set the delay as a CSS custom property:

@media (hover: hover) { .list { --delay: 0.05s; } .list li a span { transform: translateY(100px); transition: 0.2s; } .list:hover span { transform: translateY(0); } .list li:nth-child(1) span { transition-delay: calc(var(--delay) * 0); } .list li:nth-child(2) span { transition-delay: calc(var(--delay) * 1); } .list li:nth-child(3) span { transition-delay: calc(var(--delay) * 2); } .list li:nth-child(4) span { transition-delay: calc(var(--delay) * 3); } .list li:nth-child(5) span { transition-delay: calc(var(--delay) * 4); } .list li:nth-child(6) span { transition-delay: calc(var(--delay) * 5); } }

This might be a little finicky for your taste. Say your lists starts to grow, perhaps to seven or more items. The staggering suddenly isn't working on the new ones because this doesn't account for that many list items.

You could pass in the delay from the HTML if you wanted:

<ul class="list"> <li><a href="#0" style="--delay: 0.00s;">? <span>This</span></a></li> <li><a href="#0" style="--delay: 0.05s;">? <span>Little</span></a></li> <li><a href="#0" style="--delay: 0.10s;">? <span>Piggy</span></a></li> <li><a href="#0" style="--delay: 0.15s;">? <span>Went</span></a></li> <li><a href="#0" style="--delay: 0.20s;">? <span>To</span></a></li> <li><a href="#0" style="--delay: 0.25s;">? <span>Market</span></a></li> </ul> @media (hover: hover) { .list li a span { transform: translateY(100px); transition: 0.2s; } .list:hover span { transform: translateY(0); transition-delay: var(--delay); /* comes from HTML */ } }

Or if you're Sass-inclined, you could create a loop with more items than you need at the moment (knowing the extra code will gzip away pretty efficiently):

@media (hover: hover) { /* base hover styles from above */ @for $i from 0 through 20 { .list li:nth-child(#{$i + 1}) span { transition-delay: 0.05s * $i; } } }

That might be useful whether or not you choose to loop for more than you need.

The post Staggered CSS Transitions appeared first on CSS-Tricks.

Contextual Utility Classes for Color with Custom Properties

Css Tricks - Wed, 08/14/2019 - 4:08am

In CSS, we have the ability to access currentColor which is tremendously useful. Sadly, we do not have access to anything like currentBackgroundColor, and the color-mod() function is still a ways away.

With that said, I am sure I am not alone when I say I'd like to style some links based on the context, and invert colors when the link is hovered or in focus. With CSS custom properties and a few, simple utility classes, we can achieve a pretty powerful result, thanks to the cascading nature of our styles:

See the Pen
Contextually colouring links with utility classes and custom properties
by Christopher Kirk-Nielsen (@chriskirknielsen)
on CodePen.

To achieve this, we'll need to specify our text and background colors with utility classes (containing our custom properties). We'll then use these to define the color of our underline, which will expand to become a full background when hovered.

Let's start with our markup:

<section class="u-bg--green"> <p class="u-color--dark"> Lorem ipsum dolor sit amet, consectetur adipiscing elit, <a href="#">sed do eiusmod tempor incididunt</a> ut labore et dolore magna aliqua. Aliquam sem fringilla ut morbi tincidunt. Maecenas accumsan lacus vel facilisis. Posuere sollicitudin aliquam ultrices sagittis orci a scelerisque purus semper. </p> </section>

This gives us a block containing a paragraph, which has a link. Let's set up our utility classes. I'll be defining four colors that I found on Color Hunt. We’ll create a class for the color property, and a class for the background-color property, which will each have a variable to assign the color value (--c and --bg, respectively). So, if we were to define our green color, we’d have the following:

.u-color--green { --c: #08ffc8; color: #08ffc8; } .u-bg--green { --bg: #08ffc8; background-color: #08ffc8; }

If you are a Sass user, you can automate this process with a map and loop over the values to create the color and background classes automatically. Note that this is not required, it’s merely a way to create many color-related utility classes automatically. This can be very useful, but keep track of your usage so that you don’t, for example, create seven background classes that are never used on your site. With that said, here is the Sass code to generate our classes:

$colors: ( // Define a named list of our colors 'green': #08ffc8, 'light': #fff7f7, 'grey': #dadada, 'dark': #204969 ); @each $n, $c in $colors { // $n is the key, $c is the value .u-color--#{$n} { --c: #{$c}; color: #{$c}; } .u-bg--#{$n} { --bg: #{$c}; background-color: #{$c}; } }

What happens if we forget to apply a utility class in your markup, though? The --c variable would naturally use currentColor… and so would --bg! Let’s define a top-level default to avoid this:

html { --c: #000000; --bg: #ffffff; }

Cool! Now all we need is to style our link. We will be styling all links with our trusty <a> element in this article, but you could just as easily add a class like .fancy-link.

Additionally, as you may know, links should be styled in the "LoVe-HAte" order: :link, :visited, :hover (and :focus!), and :active. We could use :any-link, but browser support isn't as great as CSS custom properties. (Had it been the other way around, it wouldn't have been much of an issue.)

We can start declaring the styles for our links by providing an acceptable experience for older browsers, then checking for custom property support:

/* Styles for older browsers */ a { color: inherit; text-decoration: underline; } a:hover, a:focus, a:active { text-decoration: none; outline: .0625em solid currentColor; outline-offset: .0625em; } a:active { outline-width: .125em; } @supports (--a: b) { /* Check for CSS variable support */ /* Default variable values */ html { --c: #000000; --bg: #ffffff; } a { /* * Basic link styles go here... */ } }

Let's then create the basic link styles. We'll be making use of custom properties to make our styles as DRY as possible.

First, we need to set up our variables. We want to define a --space variable that will be used on various properties to add a bit of room around the text. The link's color will also be defined in a variable with --link-color, with a default of currentColor. The fake underline will be generated using a background image, whose size will be adjusted depending on the state with --bg-size, set to use the --space value by default. Finally, to add a bit of fun to this, we'll also fake a border around the link when it's :active using box-shadow, so we'll define its size in --shadow-size, set to 0 in it's inactive state. This gives us:

--space: .125em; --link-color: currentColor; --bg-size: var(--space); --shadow-size: 0;

We’ll first need to adjust for the fallback styles. We'll set our color to make use of our custom property, and remove the default underline:

color: var(--link-color); text-decoration: none;

Let's next create our fake underline. The image will be a linear-gradient with two identical start and end points: the text's color --c. We make sure it only repeats horizontally with background-repeat: repeat-x;, and place it at the bottom of our element with background-position: 0 100%;. Finally, we give it its size, which is 100% horizontally, and the value of --bg-size vertically. We end up with this:

background-image: linear-gradient(var(--c, currentColor), var(--c, currentColor)); background-repeat: repeat-x; background-position: 0 100%; background-size: 100% var(--bg-size);

For the sake of our :active state, let's also define the box shadow, which will be non-existent, but with our variable, it'll be able to come to life: box-shadow: 0 0 0 var(--shadow-size, 0) var(--c);

That's the bulk of the basic styles. Now, what we need to do is assign new values to our variables depending on the link state.

The :link and :visited are what our users will see when the link is "idle." Since we already set up everything, this is a short ruleset. While we technically could skip this step and declare the --c variable in the initial assignment of --link-color, I'm assigning this here to make every step of our styles crystal clear:

a:link, a:visited { --link-color: var(--c); }

The link now looks pretty cool, but if we interact with it, nothing happens… Let's create those styles next. Two things need to happen: the background must take up all available height (aka 100%), and the text color must change to be that of the background, since the background is the text color (confusing, right?). The first one is simple enough: --bg-size: 100%;. For the text color, we assign the --bg variable, like so: --link-color: var(--bg);. Along with our pseudo-class selectors, we end up with:

a:hover, a:focus, a:active { --bg-size: 100%; --link-color: var(--bg); }

Look at that underline become a full-on background when hovered or focused! As a bonus, we can add a faked border when the link is clicked by increasing the --shadow-size, for which our --space variable will come in handy once more:

a:active { --shadow-size: var(--space); }

We're now pretty much done! However, it looks a bit too generic, so let's add a transition, some padding and rounded corners, and let's also make sure it looks nice if the link spans multiple lines!

For the transitions, we only need to animate color, background-size and box-shadow. The duration is up to you, but given links are generally around 20 pixels in height, we can put a small duration. Finally, to make this look smoother, let's use ease-in-out easing. This sums up to:

transition-property: color, background-size, box-shadow; transition-duration: 150ms; transition-timing-function: ease-in-out; will-change: color, background-size, box-shadow; /* lets the browser know which properties are about to be manipulated. */

We'll next assign our --space variable to padding and border-radius, but don't worry about the former — since we haven't defined it as an inline-block, the padding won't mess up the vertical rhythm of our block of text. This means you can adjust the height of your background without worrying about line-spacing! (just make sure to test your values)

padding: var(--space); border-radius: var(--space);

Finally, to ensure the styles applies properly on multiple lines, we just need to add box-decoration-break: clone; (and prefixes, if you so desire), and that's it.

When you're done, we should have these styles:

/* Styles for older browsers */ a { color: inherit; text-decoration: underline; } a:hover, a:focus, a:active { text-decoration: none; outline: .0625em solid currentColor; outline-offset: .0625em; } a:active { outline-width: .125em; } /* Basic link styles for modern browsers */ @supports (--a: b) { /* Default variable values */ html { --c: #000000; --bg: #ffffff; } a { /* Variables */ --space: .125em; --link-color: currentColor; --bg-size: var(--space); --shadow-size: 0; /* Layout */ padding: var(--space); /* Inline elements won't affect vertical rhythm, so we don't need to specify each direction */ /* Text styles */ color: var(--link-color);/* Use the variable for our color */ text-decoration: none; /* Remove the default underline */ /* Box styles */ border-radius: var(--space); /* Make it a tiny bit fancier &#x2728; */ background-image: linear-gradient(var(--c, currentColor), var(--c, currentColor)); background-repeat: repeat-x; background-position: 0 100%; background-size: 100% var(--bg-size); box-shadow: 0 0 0 var(--shadow-size, 0) var(--c, currentColor); /* Used in the :active state */ box-decoration-break: clone; /* Ensure the styles repeat on links spanning multiple lines */ /* Transition declarations */ transition-property: color, background-size, box-shadow; transition-duration: 150ms; transition-timing-function: ease-in-out; will-change: color, background-size, box-shadow; } /* Idle states */ a:link, a:visited { --link-color: var(--c, currentColor); /* Use --c, or fallback to currentColor */ } /* Interacted-with states */ a:hover, a:focus, a:active { --bg-size: 100%; --link-color: var(--bg); } /* Active state */ a:active { --shadow-size: var(--space); /* Define the box-shadow size */ } }

Sure, it's a bit more convoluted that just having an underline, but used hand-in-hand with utility classes that allow you to always access the text and background colors, it's a quite nice progressive enhancement.

It’s up to you to enhance this using three variables for each color, either rgb or hsl format to adjust opacity and such. You can also add a text-shadow to simulate text-decoration-skip-ink!

The post Contextual Utility Classes for Color with Custom Properties appeared first on CSS-Tricks.

The Differing Perspectives on CSS-in-JS

Css Tricks - Tue, 08/13/2019 - 1:00pm

Some people outright hate the idea of CSS-in-JS. Just that name is offensive. Hard no. Styling doesn't belong in JavaScript, it belongs in CSS, a thing that already exists and that browsers are optimized to use. Separation of concerns. Anything else is a laughable misstep, a sign of not learning from the mistakes of the past (like the <font> tag and such.)

Some people outright love the idea of CSS-in-JS. The co-location of templates and functionality, à la most JavaScript frameworks, has proven successful to them, so wrapping in styles seems like a natural fit. Vue's single file components are an archetype here.

(Here's a video on CSS-in-JS I did with Dustin Schau if you need a primer.)

Brent Jackson thinks you should definitely learn it, but also offers some pragmatic points on what it does and doesn't do:

What does CSS-in-JS do?

  • Let you author CSS in JavaScript syntax
  • Colocate styles with components
  • Take advantage of native JS syntax features
  • Take advantage of anything from the JS ecosystem

What does CSS-in-JS not rid you of needing to understand:

  • How styles are applied to the DOM
  • How inheritance works
  • How CSS properties work
  • How CSS layout works

CSS-in-JS doesn't absolve you of learning CSS. Mostly, anyway.

I've heard lots of pushback on CSS-in-JS in the vein of "you people are reaching for CSS-in-JS because you don't understand CSS" or "You're doing this because you're afraid of the cascade. I already know how to scope CSS." I find that stuff to be more poking across the isles that isn't particularly helpful.

Laura buns has a wonderfully two-sided article titled "The web without the web" part of which is about React and CSS-in-JS:

I hate React because CSS-in-JS approaches by default encourage you to write completely self-contained one off components rather than trying to build a website UI up as a whole.

You don't need to use CSS-in-JS just because you use React, but it is popular, and that's a very interesting and fair criticism. If you scope everything, aren't you putting yourself at higher risk of inconsistency?

I've been, so far, a fan of CSS modules in that it's about as light as you get when it comes to CSS-in-JS, only handling scoping and co-location and that's about it. I use it with Sass so we have access to mixins and variables that help consistency, but I could see how it could allow a slide into dangerous too-many-one-offs territory.

And yet, they would be disposable one-offs. Code-splittable one-offs. Everything exists in balance.

Laura goes on to say she likes CSS-in-JS approaches for some of the power and flexibility it offers:

I like the way CSS-in-JS gives you enough abstraction to still use tricks like blind owl selectors while also giving you the full power of using JS to do stuff like container queries.

Martin Hofmann created a site comparing BEM vs. Emotion that looks at one little "alert" component. I like how it's an emotionless (literally, not referencing the library) comparison that looks at syntax. BEM has some advantages, notably, requiring no tooling and is easily sharable to any web project. But the Emotion approach is cleaner in many ways and looks easier to handle.

I'd like to see more emotionless comparisons of the technologies. Choice A does these three things well but is painful here and here, while choice B does these other things well and solves a few other pain points.

We recently linked up Scott Jehl's post that looks into loading CSS asynchronously. Scott's opening line:

One of the most impactful things we can do to improve page performance and resilience is to load CSS in a way that does not delay page rendering.

It's notable that an all-in CSS-in-JS approach gets this ability naturally, as styling is bundled into JavaScript. It's bundled at a cost. A cost to performance. But we get some of that cost back if we're eliminating other render-blocking things. That's interesting stuff worthy of more data, at least.

I might get my butt kicked for this, but I'm a bit less interested in conversations that try to blame CSS-in-JS for raising the barrier to entry in the industry. That's a massive thing to consider, but we aren't talking about shutting down CSS here and forcing everyone to some other language. We're talking about niche libraries for certain types of projects at certain scales.

I think it's worth taking a look at CSS-in-JS ideas if...

  • You're working on a component-heavy JavaScript project anyway.
  • You're already co-locating templates, functionality, and data queries.
  • You think you can leverage it without harming user experience, like gaining speed back elsewhere.
  • Your team is comfortable with the required tech, as in, you aren't pushing away talent.

Max Stoiber is an unabashed fan. His post on the topic talks about the confidence this style brings him and the time he saves in finding what he needs, both things I've found to be true. But he also thinks the approach is specifically for JavaScript framework apps.

If you are using a JavaScript framework to build a web app with components, CSS-in-JS is probably a good fit. Especially if you are part of a team where everybody understands basic JavaScript.

I'd love to hear y'all thoughts on this in the comments. Have you worked out your feelings on all this? Madly in love? Seething with dislike? I'd be most interested in hearing success stories or failure stories on real projects.

The post The Differing Perspectives on CSS-in-JS appeared first on CSS-Tricks.

Syndicate content
©2003 - Present Akamai Design & Development.