CSS

What Can You Do with Tailwind 2?

Published Nov 24, 2020

Updated Feb 14, 2023

7 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

What Can You Do with Tailwind 2?

Tailwind CSS finally announced it's new 2.0 version on November 18th, 2020.

If you've been around the industry lately, you've probably heard of Tailwind CSS, because they seem to be everywhere! But maybe you haven't, and in that case, it's time for a short introduction. If you have, skip to 2.0 Features

Intro to Tailwind CSS

Something that started out as some handcrafted CSS used personally by Adam Wathan became an extremely popular, productivity-boosting CSS framework used by millions over the last three years. The core mindset behind Tailwind is that CSS should be composed of small single-purpose utility classes which pull from a standard set of values.

At first you may think, "This seems like inline styles, why would I want to bloat my markup and aren't those bad anyway?", and while your statement about inline styles is correct, Tailwind's utility classes aren't that at all. Here's why:

By sticking with only classes, styles all stay at the same specificity.
By using classes instead of inline styles, we encourage reuse and ensure that we're sticking to a standard set of values.
While our markup may be larger than those who use other CSS methodologies, we always know exactly what styles are coming from our classes because there is a 1-to-1 mapping.
The breadth of utility classes allows us to write 95-100% of our CSS using just utilities. This encourages a small footprint and very little maintenance overhead.

There are other benefits like increased authoring speed and others that I'd like to cover in a more thorough post later.

In case you're wondering, what does this look like? Here's an example component from Tailwind's homepage:

Now that you've gotten a short introduction, let's get back to why we're here.

2.0 Features

Since this is a major version, it needed a major launch which included not only a teaser and trailer, but also a whole new website and docs! If this isn't maximalist launching, I don't know what is! Let's see the most exciting changes with a few examples that you couldn't make without customizing version 1.

Theming and Design

I don't think it would be a major version launch if Tailwind didn't touch these two topics because they are the main pillars of why we use Tailwind in the first place. They didn't just touch these though, they brought big changes.

Colors

With regards to theming and design, the biggest of change is colors. The Tailwind team created an all new color palette which includes 17 colors and 5 grays.

This is a huge jump in expressiveness for designs, especially with alternate grays because the old gray was on the cool side. The new sets add two cooler grays and two warmer grays so you can have something that jives better with your design's palette.

Color docs

Dark Mode

Another big change is the new support for dark mode. Tailwind doesn't force one color to another for dark mode, but instead let's you control which colors get applied through the new modifier dark:. This will apply whatever style follows whenever a .dark class is above it.

Dark Mode docs

New Breakpoint and Extended Scales

In an effort to support even more refined designs, the team has added support for a larger breakpoint 2xl which now allows more specification for larger layouts. I often added this as a custom breakpoint. Breakpoint docs

They also added extended scales for spacing, typography, and opacity. For spacing, a few half values were added near the bottom for nudging smaller spacing layouts. For typography, a few values were added to the top end for larger hero text. Opacity had the largest set of adds with steps every 10, and a few half steps at the ends. Spacing, typography, and opacity docs.

A Practical Look at New Theming Changes

I've put together a small demo of landing page hero to show off the new changes. Try toggling the dark class to see dark mode:

New and Extended Utilities

It wouldn't be Tailwind without utilities, and in a major launch, we're going to see some new ones. I think both the new forms plugin and ring utilities are big wins for accessibility because they encourage good practice. The new colors are sure to help us get good contrast!

Forms

Forms have always been a struggle to style. We often resort to hacks and custom implementations with Javascript to be able to make them look good and match our designs. The Tailwind team has worked hard to make standard HTML form inputs able to be styled without custom elements or hacks. There are some limitations here, but I think the result looks great.

Forms plugin docs

Ring

Another issue that we often encounter when auditing the accessibility of our apps is showing clear focus indicators. The default web version of this is accomplished through the outline property. Unfortunately, outline ignores border-radius and isn't quite as customizable as something like box-shadow. The new ring utility will use box-shadow and that will work alongside the standard shadow utilities in Tailwind without overriding them. Our focus indicators can now look as good as the rest of our UI! 💅

Ring docs

Text Overflow

A small change, but still helpful: you can now specify overflow-ellipsis and overflow-clip to control text overflow in a multi-line scenario. Text-overflow docs

Default Line-heights

Something that I feel I'm always tweaking is line-height. I think good line-heights can make or break type styles. In an effort to help improve the quality of typography in Tailwind, the team has shipped default line-heights for each text size, and like always, you can change that with the leading utility. Font-size docs

Practical Example of New Utilities

I've put together a small form component to show off the new utilities:

Internal Mechanics Changes

Quite a few internal changes have taken place, one major one being that Tailwind dropped support for IE11 in 2.0. Given that IE11 has very little representation globally and is officially unsupported by Microsoft, I think this was a good move, especially because it allows them to do even more with the framework.

In addition, @apply can now work with all variants which is a huge boost to anyone who heavily used it. Previously, you were required to implement those variants as you would normal CSS, but no longer!

Two things changed with config. You can easily extend variant's by adding an extend property to your variants config object. This allows you to just add new variants without having to list out all of the default variants which is just a lot nicer.

The other new thing in config is that we can now set default transition timings and easing functions. This allows us to no longer need to specify a duration or easing function if we're just fine with the default, which is probably 80% of the time for me personally.

@apply, variant, and transition docs

The Road to 2.0

Whether you already use Tailwind or you just got converted above, there's a lot to be excited about with version 2.0. A ton of work went into it and it shows in the quality of what was launched.

Creating and maintaining Tailwind quickly became the work of a small company, unfortunately Adam is only so powerful 🤣. He and Steve Schoger needed extra help which they found this year using funds made from their launch of TailwindUI and RefactoringUI. They hired Brad Cornes, Robin Malfait, and Simon Vrachliotis to assist with developing the entire ecosystem that surrounds Tailwind and to push out this new version.

The team's desires for the new version were deliberated at length over many of Adam's tweets, Github issues/discussions, and even podcast episodes from Adam's very own Full Stack Radio. Something especially important to point out is the team's desire to stick to semantic versioning. Creating a new version opens up a lot of doors for change which is great, but that door also closes at the same time. Now the Tailwind team has to wait until 3.0 to make changes that will break, but I think they made good calls on what to include in this version.

What's Next?

If you're as excited as I am, you can head straight to this upgrade guide to dig through what changes you might need to make in your current Tailwind codebase. If you'd like to hear more straight from the creators themselves head on over to their announcement blog post to get an in-depth look at each change.

For some of us, it might not be time to change and that's ok. The current version is still a serious piece of craftsmanship with all the same well-thought features. Version 1.9 will be the last update in version one and will retain support for IE11.

I think Tailwind has proved to be more future-thinking than most frameworks to date including frameworks in other languages. Their attention to detail and quest for excellence shows up in the quality of their work. As a company, they're just getting started. Hopefully the future holds even more new innovations in this lovely little CSS framework, and beyond!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Hunter Miller
@hmillerdev @arthyn

The CSS / Utility hybrid approach with Tailwind v4

Just recently, the progress on the next major version of Tailwind CSS was open-sourced, along with a preview post. This is very exciting news to me, and I love the direction they’ve taken with this release. Tailwind can be a pretty polarizing topic among developers, but I believe that we can find some common ground and live in harmony. In this post, we’ll look at how the CSS + Tailwind hybrid approach is getting an upgrade in v4 and some of the patterns that we can take advantage of to provide a stellar styling experience on our websites. The hybrid approach It doesn’t matter what your personal take on Tailwind is, the fact is utility classes are an incredibly useful pattern for styling websites with CSS. I’m not sold on the hard-line, all-or-nothing approach that Tailwind has always recommended. Having a class string that extends way off the screen on an ultra-wide monitor is not pretty. Combining traditional CSS classes with utility classes helps cut down on the styling noise in your markup and provides some advantages when applied correctly. This post will cover some useful patterns and best practices for using CSS and Tailwind in harmony Tailwind going “CSS-native” In the v4 introduction post, they state A major goal of Tailwind CSS v4.0 is making the framework feel CSS-native, and less like a JavaScript library. I love that they are heading in this direction, and I’m imagining Tailwind as the toolkit for styling websites with CSS. It is going to replace the plethora of tools from the past and provide support for all the modern niceties like: * Importing CSS files with @import * Vendor prefixing _(no more autoprefixr)_ * Improved browser support for modern features like CSS nesting and media query ranges. This means less worry for us as developers. We can write our code and build our sites using the modern features that the platform provides without sweating all the other details and edge cases. The talented folks at Tailwind and the open-source community have our backs. Tailwind v4 CSS configuration The biggest step in the “CSS-native” direction and the feature that I’m most excited about is the CSS configuration. This is great for embracing CSS and Tailwind as one instead of two factions at battle. If you’ve been using Tailwind exclusively for a long time like I have, you might be out of touch with all the great features and tools that CSS provides out of the box now. This is a great opportunity to get back to learning and using the platform. In Tailwind v4 we do our configuration and theming with CSS variables. To get an idea of what this looks like check out the default theme on GitHub. In our configuration we can override any values from the default theme or extend it with new values. ` All the values from the theme are exposed as CSS variables. We can reference them in our CSS files or directly in our utility classes. ` ` Best practices for combining CSS with utility classes I can understand why Tailwind recommends using strictly utility classes. It’s easy to shoot yourself in the foot and run into the issues that utility classes set out to solve in the first place. I believe if you follow some general guidelines you can safely have the best of both worlds. Create focused/specialized classes CSS tends to get messy when we use classes that are overly specific with styles that apply to just one or a small number of use cases. Take a calendar where the days are custom checkboxes. You might have some pretty specialized styles for this bit of UI. ` Notice that we just add some specific styles that apply to this use case. This gives us the flexibility to keep composing our styles with utility classes. Some things are better left to utilities The best way to avoid wandering too far off the path of enlightenment is to stick with utility classes for certain (most?) things. Spacing and layouting are examples of things that are probably best left to utility classes. These typically vary all across a page, and encoding them in a class will make it a lot less flexible. A code smell to look out for: If you have abstracted something to a class and you end up overriding certain aspects of its styles in different places. Those styles should probably be utility classes. Classes as components Tailwind has always recommended using a component system for your UI components so that your utility classes are all defined in a single place. You don’t want to have to edit 50 different files to make a change to the style of your buttons across your website. I’ve found that defining things that might be simple “components” like buttons, badges, links, etc as classes works just as well in most cases. You can use Tailwind CSS with the @apply directive or traditional class definitions for this: ` You can even bring the BEM naming convention back to compose variants on top of base component styles. (or name them however you’d like!) ` Now we can easily define badges in our markup: ` Modern CSS and other interesting utility hybrid patterns I think a lot of us are realizing that modern CSS is pretty great. There are a ton of awesome new features gaining support across major browsers, like CSS nesting, container queries, and more! More and more people are also coming around to the utility of utility classes. If you want to dive deeper and see other interesting approaches and patterns when combining modern CSS with utility classes, check out the post: Modern CSS patterns in Campfire. Summary I’m looking forward to the Tailwind CSS configuration and other awesome updates coming in v4. Using Tailwind doesn’t have to be a one-size-fits-all approach. If you want to write some CSS, I say go for it! Hopefully, some of the points in this post will lead to success if you decide to do so....

May 10, 2024

4 mins

Tailwind CSSCSS

:where functional pseudo-selectors :is valuable in CSS

If you’ve written CSS before, you’ve used pseudo selectors. Typically, we’d use them to style :hover events or select every :nth-of-type() In recent years CSS has become a lot more powerful, and with that, we now have many more pseudo-selectors available to use. Let’s explore some functional pseudo-selectors together and see how to use them to enhance our front-end code. Functional pseudo-classes While there are a wide range of pseudo-classes, I want to focus on the _functional_ ones today. :is :is works very similar to a regular CSS class list at first glance ` One of its main benefits is that you can group CSS classes to form more readable and maintainable conditions. ` For deep nesting, this can make your CSS significantly easier to understand, simplifying editing at a later date. ` You may be thinking that CSS has another solution that improves readability in a similar way: nesting. That’s true, and in this context, you can use them interchangeably, though the syntax is still shorter. ` However deeper nesting using nested CSS can become complex quickly. Sometimes it makes sense to use :is to help avoid this complexity. ` :is also provides a specificity modifier you don’t get with nested css. If you write: ` Every selector within the:is would be treated as if it had the same specificity value as the ID. With :is, the highest value applies to all other values within the :is. This does not apply to nested CSS. :not It does exactly what you think it does. The :not selector grabs everything _except_ the classes you define: ` Like the other pseudo-classes, you can negate multiple classes if you choose: ` This can be powerful when combined with other pseudo-selectors: ` :where Using the :where pseudo-class is great for creating low-specificity CSS. If you create a library or plugin that’s going to be used by other people and you want them to style it themselves, but don’t want it to appear ugly when they first set it up, :where is the way to do that. For example, let’s style all our links with an underline using :where ` With this approach, we can override our link’s default styles without having to create difficult to maintain CSS: ` If we didn't use :where above, import order would matter if we wanted to override this. But because we planned ahead, we can just use a standard a tag. Without using :where we’re stuck with options that are much harder to work with: ` :where also has the same benefits of class grouping that :is does but without the specificity, so you can do something like this and then override it easily later. ` :has One of the most powerful pseudo selectors is :has, which gives you the option to style a tag or class based on other classes or tags associated with it. ` An incredible benefit :has brings is the ability to create parent selector functionality. This gives you a wide variety of options to style the parent based on the state of the children. ` You can also combine this with the :not selector to select elements that don’t have specific children. ` Benefits of Pseudo-Classes Readability One of the benefits of all of these pseudo-selectors is that they can act similarly to nested CSS. It’s possible to use these to make your code more readable. ` Using :is this way is effectively the same as using nested CSS, but if you need lower specificity you could use :where, or :not if you want to exclude (instead of include) some classes. Functionality :not and :has provide new options which weren’t possible before, allowing you to style more dynamically and provide better experiences while simplifying your code. Before these options were available, the only solution was to style the code using JavaScript. While this technically allows you to achieve your styling goals, it’s not ideal. Mixing CSS operations into JS files makes it much harder to maintain long-term because it adds a layer of abstraction to your solution, while the built-in CSS option is much simpler. While :is and :where don’t provide as much new functionality, they still allow you to write more understandable CSS with less ambiguity or workarounds, making maintenance significantly easier. Summing up Modern CSS allows us to be much more flexible with our styles, all while writing less code. Simplifying CSS and removing the need to compensate, either by writing extra CSS or styling through JS, means our CSS files are more explicit and easier to maintain in the long term. They may not be needed often, but they’re an incredibly important part of your front-end toolbelt. Have you found any interesting ways to use functional pseudo-classes? Send us a post on X or message us on LinkedIn and show me what cool things you’ve made....

Aug 9, 2024

4 mins

CSS

Why You Should Use React Query or SWR

Why You Should Use React Query or SWR for External Data Most of us out here in React-land are out building our apps with the shiny new Hooks API and slinging requests to external APIs like nobody's business. Those of us new to hooks may have started creating hooks that look like this simplified example: ` The Problem However, each time a hook is called, that instance is unique to the component it was called in, so there's a few issues we'll run into: 1. Updating the above query in one instance won't update it for the other instances. 2. If we have three components using a hook that makes an API request, we will get at least one request per component. 3. If we have multiple requests in the air, and we try to store them in a global store or have the hook hold the state, we will end up with state out of sync or subsequent requests overwriting each other. One way to solve this is to leave the request out of hooks and only call it on mount in a component you can guarantee will be singular (aka a singleton component, like a page/route perhaps). Depending on how that data is used, this can sometimes be very tricky to do. Potential Solutions So what can we do? There are a few options: 1. Make sure the data returned from the API goes in context or some kind of global state management, accepting the multiple requests (potentially overexerting our server's API) 2. Doing the above + use a library like react-singleton-hook, ensure there's only a single component with the useEffect doing the API call, or similar to prevent multiple requests. 3. Implement some kind of way to cache the data (while still being able to invalidate that as necessary) so that we pull from the cache first 4. Use React Query or SWR The Real Solution The real solution here is to use option 4. Both libraries have done really sophisticated work to solve these problems to prevent you from having to do it yourself. Caching is extremely tricky to get right and can have pretty dire consequences if done poorly, leading to your app partially or completely breaking. Other Problems They Solve Here are a few examples of other problems these libraries can solve with code examples for each. _Code examples are using React Query but are nearly the same with SWR._ Window Focus Refetching One big issue that we encounter with Javascript heavy sites and apps is that a user may be on one tab/window messing with data and then switch to another of the same app. The problem here is that if we aren't keeping our data fresh, these can fall out of sync. Both libraries solve this by refetching data once the window has focus again. If you don't need that or can't have that behavior, you can simply disable as an option. ` Request Retry, Revalidation and Polling Sometimes requests error temporarily, it happens. Both libraries answer this problem by allowing configured automatic retries, so anytime they encounter an error, it will retry the specified amount of times until finally throwing an error. Additionally, you can use either to poll an endpoint constantly by just setting their refetch/refresh interval to a number in milliseconds. Retry Example ` Polling Example ` Mutation with Optimistic Updates Let's say you have a list of users and you want to update the information of one of those users, a pretty standard operation. Most people are pretty content with seeing a loader to indicate the server is working to update that user, and waiting for it to finish before seeing the updated list of users. However, if we know what the updated list of users will look like locally (because the user just made the update themselves), do we really even need to show a loader? No, both libraries allow you to do mutations on your cached data that will update locally immediately and start the update to the server in the background. They will also make sure that data gets refetched/validated to be the same once it returns from the server, and if not, the returned data will fall into place. Imagine we have a page where the user gets to edit their information. First, we need to fetch that information from the backend. ` Next we need to setup a function to allow us to update the user's data once they submit the form. ` If we want to have our local data update the UI optimistically, we have to add some options to the mutation. The onMutate here will shove the data locally into the cache firing before the actual update so our UI won't show a loader. The return value is used in case of an error, and we need to reset to our previous state. ` If we're updating optimistically, we need to be able to handle errors and also make sure that the server returns the same data. So we add two more hooks into our mutation's options. onError will use the data returned from onMutate so that we can reset to the previous state. onSettled makes sure we refetch the same data from the server so that we don't end up out of sync. ` Prefetching and Background Fetching If you have an idea about some data that the user is about to need, you can use these libraries to prefetch that data. By the time the user gets to it, the data is already loaded making the transition instant. This can really make your apps feel snappier. ` On a similar note, if the user already has received some data, but it's time to refresh, the libraries will fetch new data behind the scenes and replace the old data if and only if that data is different. This prevents showing the user a loading indicator, only notifying them if there's something new which is a much better user experience. Imagine we have a Twitter-style feed component that constantly is refetching for new posts ` We can notify users that the data is upgrading in the background by listening for isFetching to be true which will fire even if cache data is present. ` If we have no data in the cache at all and the query is fetching data, we can listen for isLoading to be true and show some kind of loading indicator. Finally, if isSuccess is true and we received data, we can display the posts themselves. ` Feature Comparison React Query's creator did a great job building out a feature table comparison for React Query, SWR, and Apollo for you to see what features are available. One big feature that I'd like to call out that React Query has over SWR is it's own set of dev tools which are really helpful for debugging misbehaving queries. Conclusion Over my time as a developer, I've tried to solve these problems myself, and had I had a library like React Query or SWR, I would have saved a ton of time. These problems can be really tricky to solve and the solutions can inject subtle bugs into your app that are difficult or time-consuming to debug. Luckily, we have open source and these people were generous to offer their own robust solutions for us to use. If you'd like to see more about the problems these libraries solve and the efforts needed to solve them, Tanner Linsley did a great walkthrough of what he was experiencing and how he solved it. You can watch that walkthrough here: Overall I think these libraries are great additions to the ecosystem and will help us all write better software. I'd like to see other frameworks come out with similar libraries, because the concepts here are pretty universal. I hope you found this helpful and let us know any unique strategies you have when using these libraries! PS. What about GraphQL? 😂 Well, a lot of the GraphQL libraries out there actually built in a lot of these concepts from the get go, so if you're using something like Apollo or Urql, you probably are already getting these benefits. However, both libraries are compatible with anything that returns a promise, so if your particular favorite GQL library doesn't have these features, try putting React Query or SWR in front of it. 😁...

Sep 25, 2020

6 mins

JavaScriptReact

D1 SQLite: Writing queries with the D1 Client API

Writing queries with the D1 Client API In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post. We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts. Prepared statements and parameter binding This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements. We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations. By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion. ` I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding. ` Reusing prepared statements If we take the first example above and not bind any values we have a statement that can be reused: ` Querying For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries. select queries Let's write our first query against our data set to get our feet wet. Here’s the initial worker code and a query for all authors: ` We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query. We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results. joins Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information. ` Let’s walk through each part of the query and highlight some pros and cons. ` * The query selects all columns from the posts table. * It also selects the name column from the authors table and renames it to author_name. * It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags. ` * The query starts by selecting data from the posts table. * It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors. * Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags. * Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags. * Finally, group the results by the post id so that all rows with the same post id are combined in a single row SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please. Our results should look similar to this: ` This brings us to our next topic. Marshaling / coercing result data A couple of things we notice about the format of the result data our query provides: Rows are flat. We join the author directly onto the post and prefix its column names with author. ` Using an ORM we might get the data back as a child object: ` Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves. ` This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want. This problem is handled in most ORM’s and is their main selling point in my opinion. insert / update / delete Next, let’s write a function that will add a new post to our database. ` There’s a few queries involved in our create post function: * first we create the new post * next we run through the tags and either create or return an existing tag * finally, we add entries to our post_tags join table to associate our new post with the tags assigned We can test our new function by providing post content in query params on our index page and formatting them for our function. ` I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great And got a new post with the id 11. UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways. To update the post we can write a query that looks like this: ` COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default. We can delete our new post with a simple DELETE query: ` Transactions / Batching One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though. According to the docs: Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence. ` Summary In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications....

Dec 23, 2024

6 mins

JavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

What Can You Do with Tailwind 2?

What Can You Do with Tailwind 2?

Intro to Tailwind CSS

2.0 Features

Theming and Design

Colors

Dark Mode

New Breakpoint and Extended Scales

A Practical Look at New Theming Changes

New and Extended Utilities

Forms

Ring

Text Overflow

Default Line-heights

Practical Example of New Utilities

Internal Mechanics Changes

The Road to 2.0

What's Next?

Hunter Miller

You might also like

The CSS / Utility hybrid approach with Tailwind v4

:where functional pseudo-selectors :is valuable in CSS

Why You Should Use React Query or SWR

D1 SQLite: Writing queries with the D1 Client API

Let's innovate together!

You might also like

The CSS / Utility hybrid approach with Tailwind v4

:where functional pseudo-selectors :is valuable in CSS

Why You Should Use React Query or SWR

D1 SQLite: Writing queries with the D1 Client API