How To Use The Vite Build Tool with React — Vite is hot, in part, because it’s based on esbuild and wickedly fast. It’s from Evan You of Vue fame, but it’s not a Vue-specific tool. Here, NARUHODO covers how to configure it to work with React.
React Architecture: How to Structure and Organize a React Application — Tania Rascia with “an opinionated guide” on project structure. Looks pretty nice to me. I like the @ import aliases. Looks like it would support a monorepo-type environment pretty well. I also like the distinction between global vs. resuable components (called just “components” here) and views vs. pages. I’d probably separate into three: Library Components (no global state, no queries/mutations, more design-y and intentionally reusable), Project Components (business logic, global state, not very reuable), and Pages (routing concerned).
What’s NOT new in React 18 — Benny Powers is a little salty about React’s lack of support. I agree it’s unfortunate, as web components do some things really well and React does some things really well and it would be nice to see them make buddies.
How React got Traction — A bit of irony when considering the above link… Shawn Wang and Pete Hunt talk on this podcast about the history of React and how it came to be so popular: “How React overcame its haters: by listening.”
Compound Components In React — Ichoku Chinonso covers this super useful pattern. Some components are built from a bucket of other little components (think Tabs, TabBar, Tab, TabPanels, TabPanel) and, with the Compound Component model, you get more flexibility, logical importing, and usage of the whole lot. I’m curious about the origins of this pattern. I know Ryan Florence was talking about it in 2017 because I first saw Kent Dodds pointing to it. Googlin’ around, there are loads of random articles about it. Maybe it comes from deeper computer science concepts?
The Perils of Rehydration — Josh Comeau covers a bug that I’ve had to fight against multiple times in the last few weeks: React looking like it’s completely pooping the bed on constructing the DOM. Like elements that are clearly nested properly in the JSX appearing in parent elements, or like you’ve forgotten to close half your dang HTML elements and the browser is majorly confused. The problem comes from trying to do server side rendering (SSR) and client side rendering (CSR), which confuses the rehydration. The DOM from the SSR doesn’t match when CSR takes over. Fortunately, there is some fairly straightforward trickery to fix it.
While I’m a front-end developer at heart, I’ve rarely had the luxury of focusing on it full time. I’ve been dipping in and out of JavaScript, never fully caught up, always trying to navigate the ecosystem all over again each time a project came up. And framework fatigue is real!
So, instead of finally getting into Rollup to replace an ancient Browserify build on one of our codebases (which could also really use that upgrade from Polymer to LitElement…), I decided to go “stackless”.
I’m certainly not dogmatic about it, but I think if you can pull of a project with literally zero build process. It feels good while working on it and feels very good when you come back to it months/years later. Plus you just pick up and go.
Imports, yo — they go a long way.
Native support for modularity is the most important step towards a build-free codebase. If I had access to only one ES6 feature for the rest of my life, I’m confident that modules would take me most of the way there when it comes to well-structured native JavaScript.
That last sentence in the post is a stinger. I’d say we’re not far off.
Directives are one of GraphQL’s best — and most unspoken — features.
Let’s explore working with GraphQL’s built-in schema and operation directives that all GraphQL spec compliant APIs must implement. They are extremely useful if you are working with a dynamic front-end because you have the control to reduce the response payload depending on what the user is interacting with.
An overview of directives
Let’s imagine an application where you have the option to customize the columns shown in a table. If you hide two or three columns then there’s really no need to fetch the data for those cells. With GraphQL directives, though, we can choose to include or skip those fields.
The GraphQL specification defines what directives are, and the location of where they can be used. Specifically, directives can be used by consumer operations (such as a query), and by the underlying schema itself. Or, in simple terms, directives are either based on schema or operation. Schema directives are used when the schema is generated, and operation directives run when a query is executed.
In short, directives can be used for the purposes of metadata, runtime hints, runtime parsing (like returning dates in a specific format), and extended descriptions (like deprecated).
Four kinds of directives
GraphQL boasts four main directives as defined in the specification working draft, with one of them unreleased as a working draft.
@include
@skip
@deprecated
@specifiedBy (working draft)
If you’re following GraphQL closely, you will also notice two additional directives were merged to the JavaScript implementation that you can try today — @stream and @defer. These aren’t part of the official spec just yet while the community tests them in real world applications.
@include
The @include directive, true to its name, allows us to conditional include fields by passing an if argument. Since it’s conditional, it makes sense to use a variable in the query to check for truthiness.
For example, if the variable in the following examples is truthy, then the name field will be included in the query response.
query getUsers($showName: Boolean) {
users {
id
name @include(if: $showName)
}
}
Conversely, we can choose not to include the field by passing the variable $showName as false along with the query. We can also specify a default value for the $showName variable so there’s no need to pass it with every request:
query getUsers($showName: Boolean = true) {
users {
id
name @include(if: $showName)
}
}
@skip
We can express the same sort of thing with just did, but using @skip directive instead. If the value is truthy, then it will, as you might expect, skip that field.
query getUsers($hideName: Boolean) {
users {
id
name @skip(if: $hideName)
}
}
While this works great for individual fields, there are times we may want to include or skip more than one field. We could duplicate the usage of @include and @skip across multiple lines like this:
query getUsers($includeFields: Boolean) {
users {
id
name @include(if: $includeFields)
email @include(if: $includeFields)
role @include(if: $includeFields)
}
}
Both the @skip and @include directives can be used on fields, fragment spreads, and inline fragments which means we can do something else, like this instead with inline fragments:
query getUsers($excludeFields: Boolean) {
users {
id
... on User @skip(if: $excludeFields) {
name
email
role
}
}
}
If a fragment is already defined, we can also use @skip and @include when we spread a fragment into the query:
fragment User on User {
name
email
role
}
query getUsers($excludeFields: Boolean) {
users {
id
...User @skip(if: $excludeFields)
}
}
@deprecated
The @deprecated directive appears only in the schema and isn’t something a user would provide as part of a query like we’ve seen above. Instead, the @deprecated directive is specified by the developer maintaining the GraphQL API schema.
As a user, if we try to fetch a field that has been deprecated in the schema, we’ll receive a warning like this that provides contextual help.
In this example, the title field has been marked deprecated and the directive provides a helpful hint to replace it.
To mark a field deprecated, we need to use the @deprecated directive within the schema definition language (SDL), passing a reason inside the arguments, like this:
type User {
id: ID!
title: String @deprecated(reason: "Use name instead")
name: String!
email: String!
role: Role
}
If we paired this with the @include directive, we could conditionally fetch the deprecated field based on a query variable:
fragment User on User {
title @include(if: $includeDeprecatedFields)
name
email
role
}
query getUsers($includeDeprecatedFields: Boolean! = false) {
users {
id
...User
}
}
@specifiedBy
@specifiedBy is the fourth of the directives and is currently part of the working draft. It’s set to be used by custom scalar implementations and take a url argument that should point to a specification for the scalar.
For example, if we add a custom scalar for email address, we will want to pass the URL to the specification for the regex we use as part of that. Using the last example and the proposal defined in RFC #822, a scalar for EmailAddress would be defined in the schema like so:
It’s recommended that custom directives have a prefixed name to prevent collisions with other added directives. If you’re looking for an example custom directive, and how it’s created, take a look at GraphQL Public Schema. It is a custom GraphQL directive that has both code and schema-first support for annotating which of an API can be consumed in public.
Wrapping up
So that’s a high-level look at GraphQL directives. Again, I believe directives are a sort of unsung hero that gets overshadowed by other GraphQL features. We already have a lot of control with GraphQL schema, and directives give us even more fine-grained control to get exactly what we want out of queries. That’s the sort of efficiency and that makes the GraphQL API so quick and ultimately more friendly to work with.
And if you’re building a GraphQL API, then be sure to include these directives to the introspection query.. Having them there not only gives developers the benefit of extra control, but an overall better developer experience. Just think how helpful it would be to properly @deprecate fields so developers know what to do without ever needing to leave the code? That’s powerful in and of itself.
Why do you pick a book at a store or go for a movie?
It’s probably because you heard great reviews about it or you “opted in” because something about it caught your attention.
You’d go back looking for new releases of the book and the movie only if the author and the director are consistent in their efforts to give you the best work.
Won’t you?
So, how different is a newsletter from this?
Honestly, not much!
A newsletter like a book or a movie is when an audience genuinely opt-in to hear from you because they find you promising, useful, and unique.
If your newsletter, like an interesting book or a movie, does not make the reader want to grab popcorn and fully indulge in the content, don’t bother writing at all!
Newsletters are not another task to be checked off on your to-do list.
You’ve got to have a lot of passion to be able to spin a story, sketch a screenplay, and make your newsletters a blockbuster hit!
Why Should Your Newsletters Be Read?
Before we delve into how to write a newsletter that gets read, let’s first find answers to why it should get read in the first place.
Increase brand awareness
Nudge users to move further down the funnel
Engage your audience with useful content
Share product and feature updates
Become a thought leader
5 Steal-Worthy Strategies To Make Your Newsletters Irresistible To Read
1. Stick to the magical three-step formula
A magical three-step formula to an engaging newsletter is an attractive subject line, compelling email copy, and also measuring the success of your content to understand what works and what doesn’t.
Attractive subject line copy + Key elements = Higher open rates
The starting point to an email content that wants to be read is an attractive subject line. Here are some pointers on making your subject lines attractive:
Personalize your subject lines with the recipient name, company name, or any other relevant attribute
Add emojis to make it instantly relatable
Breakthrough the inbox clutter by creating urgency (use words like “hurry”, “expires”, “limited”, “soon”, and more)
Intrigue the recipient with a question
Phase-out bland subject lines and incorporate the art of storytelling. Try analogies, metaphors, and more
Bonus Tip: Be Data-driven
Tap into customer interests. Base your subject lines on your subscribers’ last activity on your store, last purchase, tastes and preferences, and more.
Ex: If you have a food delivery app and see that a customer orders pizzas way too often in the nighttime, your subject lines should be something like this:
, It’s almost dinner time, let’s order your favorite pizza
Based on what we just discussed, you’d know the key elements now! To summarize,
Emojis
Personalization tag
Data-driven
Punctuations
Good design + Mobile responsiveness = Better engagement
Attractive subject lines are just the tip of an iceberg, more like luring in your audiences for the real feast – your email copy (will be discussed later) and design.
So, what is a good design?
A clean layout without any intrusive elements
Rich in graphics – charts, images, gifs, videos, or any other entertaining media asset
A layout that is mobile responsive
Monitor your metrics
I cannot stress this enough! Whether your newsletter gets read or not largely depends on understanding your audience.
Dig into the data and understand your metrics. What type of content has the most and least engagement
What does the majority of your audience like
What content resonates with your audience segments
How can you tweak your content to get the maximum engagement
Needless to say,
Higher open rates + Better engagement + Monitoring the metric = Email Newsletter Success
2. Write like you talk: Treat your subscribers like your pals
Your newsletters may reach hundreds of thousands of subscribers. But, if you want the email to be read, you should make the email sound like a personal one-to-one conversation rather than a lousy blast.
Phase-out generic content and add some pop, fizz, and pizzaz!
Here’s a good example from Lessonly. After I subscribed to Lessonly, I started receiving a series of emails from them based on my interaction. This is a great example of how to keep the tone friendly, conversational, light, and lifelike 🙂
Pro tips to make your emails look personal [Like a 2 am phone call to your BFFs] ?
Make sure that it’s from an individual and not under a brand’s name
Use a simple conversational tone
Avoid using jargon unless your audience can digest it
Switch between plain text emails and design-heavy emails
Break down your content into bullets and make it instantly skimmable
Be conversational with your sign-off (Try “Talk soon”, “Cheers”, “Good day” etc. instead of the usual “Regards”)
Note? Don’t go overboard with this strategy as there’s a fine line between being friendly and creepy!
3. Be useful and have solid takeaways
Newsletters are not a channel to load promotional emails.
If that’s the objective, I’m sorry to break the bubble – it ain’t gonna happen!
Emails are a great channel for you to connect with your customers, educate them, entertain them, solve their problems, hear about their appreciation and woes, and also promote.
It’s just a small piece of the pie.
Email Newsletters must be leveraged to optimize customer experience, heavily.
Think about it.
Your typical subscriber has an inbox flooded with emails. Ask yourself why should they take the time to open your email, read it, and take action?
They should do so because your newsletters cover the following:
Tips and tricks pertaining to the industry are shared in the body of the email itself and not a random link to a blog
Diverse content resources for free – ebooks, whitepapers, blogs, webinars, infographics, videos, and more that cover different stages of a buyer’s journey
An opportunity to hit reply and have all their doubts and queries answered
4. Tap on emotions and trigger response
There’s no marketing without emotions. Think about how Apple manages to get hundreds and thousands of customers excited about their launches.
Through teasers and keynotes, they trigger the emotion of excitement and curiosity and reap the benefits of massive sales on their launch day.
Similarly, your newsletters must also appeal to reader’s emotions for them to connect with you.
Let’s look at some trigger words to instill emotions in your newsletters.
How to map the emotions with your objectives?
Instill the emotion of curiosity for your launches
Instill the emotion of happiness for the brand’s as well as user’s milestones
Instill the emotion of urgency for your offers, sale, and discounts
Instill the emotion of information to get your content across to your audience
Instill the emotion of action for your marketing goals
5. Segment your audience
The foundation to getting your newsletters to read is segmenting your audience. This is a crucial step because people read only when they are relevant.
Imagine opening your newsletter by checking upon your subscriber who lives in Newyork regarding a recent storm that happened in California.
You’ll look like a bot that the user wants to unsubscribe from with no second thoughts.
Don’t be vague and generic with your segmentation as rightly pointed out by Marketoonist.
On what basis should you segment your subscribers?
Geography
Demography
Interaction with your website
Stage in the marketing funnel
Tastes and preferences
Past purchases
Depending on the nature of your business, the segmentation goals may widely vary!
Wrapping Up
When you put in a lot of effort and have the drive to make your newsletters the talk of the town, I’m sure you can see a lot of ROI from it,
But, more often than not, the interest tends to slowly fade away and the quality of the newsletter starts to dwindle.
You have to constantly make efforts to ensure that your newsletter gets read and engaged with.
Spend time on writing a kickass copy and as far as the design, mobile responsiveness, and layout are concerned you may want to consider some good tools.
There are tools for email newsletters like BayEngage, Hubspot, and Mailchimp. You may want to consider some alternatives too!
I hope these tips come in handy!
If you have any other tips, do share them in the comments and I’d be happy to chat!
