Most of the behavior in an application revolves around events. User enters a value in the registration form? Event. User hits the submit button? Another event. Events are triggered a number of ways and we build applications to listen for them in order to do something else in response.
You may already be super comfortable working with events based on your existing JavaScript experience. However, React has a distinct way of handling them. Rather than directly targeting DOM events, React wraps them in their own event wrapper. But we’ll get into that.
Let’s go over how to create, add and listen for events in React.
Creating Events
We’ll start by creating a form that has an input and a button. An event will be triggered when a value is entered. The button is used to call a function which will reverse that value.
Here’s how it’ll work:
An empty input field allows the user to enter text.
An onChange event is triggered when values are entered in the input. This calls a function — handleChange() — that is used to set a new state for the input.
When the „Reverse Text” button is clicked, another event is triggered. This calls a function — handleReverse() — to set a new state for reversedText.
Here’s that translated into code:
class App extends React.Component {
state = {
/* Initial State */
input: "",
reversedText: ""
};
/* handleChange() function to set a new state for input */
handleChange = event => {
const value = event.target.value;
this.setState({
input: value
});
};
/* handleReverse() function to reverse the input and set that as new state for reversedText */
handleReverse = event => {
event.preventDefault();
const text = this.state.input;
this.setState({
reversedText: text
.split("")
.reverse()
.join("")
});
};
render() {
return (
<React.Fragment>
{ /* handleReverse() is called when the form is submitted */ }
<form onSubmit={this.handleReverse}>
<div>
{ /* Render input entered */}
<label>Text: {this.state.input}</label>
</div>
<div>
{ /* handleChange() is triggered when text is entered */ }
<input
type="text"
value={this.state.input}
onChange={this.handleChange}
placeholder="Enter a text"
/>
</div>
<div>
<button>Reverse Text</button>
</div>
</form>
{ /* Render reversed text */}
<p>Reversed Text: {this.state.reversedText}</p>
</React.Fragment>
);
}
}}
No, it won’t because you can only listen to events on DOM elements. We touched on this at the beginning of the post, but React components are wrappers for DOM elements. That means we essentially have a layer that we need to pass through to listen for the event.
The way around this is to pass the event handler as a prop to the child component. Then the prop is passed down to the click event as an attribute like so:
There may be times when you want to make use of certain DOM events that are triggered when the component is mounted. Let’s see this using the resize event — we want to see the width of the window whenever it is resized.
If we create a component and try it out like we have below, then the event will not be triggered. We’ll need to add the event listener (handleResize() in this case) and the event type like we have here:
Now, the event listener will be added when the component mounts. That means our component is actively listening to the browser window and will display its width when it updates.
In summary
OK, so we covered quite a bit of ground in a very small amount of space. We learned that React does not connect directly to a DOM event, but rather Synthetic Events that are wrappers for DOM events. We dug into the process for creating event listeners so that they attach to Synthetic Events and, from there, made sure that a component will update when those events are triggered.
I’m very glad a guide for these features exists because we already know there are so many weird things that variable fonts can do — well done, Tunghsiao Liu!
I’m very glad a guide for these features exists because we already know there are so many weird things that variable fonts can do — well done, Tunghsiao Liu!
Early in my career when I worked at agencies and later at Microsoft on Edge, I heard the same lament over and over: „Argh, why doesn’t Edge just run on Blink? Then I would have access to ALL THE APIs I want to use and would only have to test in one browser!”
Let me be clear: an Internet that runs only on Chrome’s engine, Blink, and its offspring, is not the paradise we like to imagine it to be.
As a Google Developer Expert who has worked on Microsoft Edge, with Firefox, and with the W3C as an Invited Expert, I have some opinions (and a number of facts) to drop on this topic. Let’s get to it.
What is a browser, even?
Let’s clear up some terminology.
Popular browsers you know today include Google Chrome, Apple Safari, Mozilla Firefox, and Microsoft Edge, but in the past we’ve also had such greats as NCSA Mosaic and Netscape Navigator. Whichever browser you use daily (I use Firefox, thanks for asking) is only an interface layer wrapped around a browser engine. All your bookmarks, the forward and backward arrows, that URL bar thingy—those aren’t the browser. Those are the browser’s interface. Often the people who build the browser’s engine never even touch the interface!
Browser engines are the things that actually read all the HTML and CSS and JavaScript that come down across the Internet, interpret them, and display a pretty picture of a web page for you. They have their own names. Chrome’s engine is Blink. Safari runs on WebKit. Firefox uses Gecko. Edge sits on top of EdgeHTML. (I like this naming convention. Good job, Edge.)
Except for Edge, all of these engines are open source, meaning anybody could grab one, wrap it in a new interface, and boom, release their own browser—maybe with a different (perhaps better) user experience—and that’s just what some browsers are! Oculus Browser, Brave, Vivaldi, Samsung Internet, Amazon’s Silk, and Opera all run on Blink. We call them “Chromium-based browsers”—Chromium is Google’s open source project from which Chrome and its engine emerged.
But what’s inside a browser engine? MOAR ENGINES! Every browser engine is comprised of several other engines:
A layout and rendering engine (often so tightly coupled that there’s no distinction) that calculates how the page should look and handles any paints, renders, and even animations.
A JavaScript engine, which is its own thing and can even run independently of the browser altogether. For instance, you can use Chrome’s V8 engine or Microsoft Edge’s Chakra to run Node on a server.
I like to compare browser engines to biological cells. Where a cell contains many organelles to perform different functions, so too do browsers. One can think of the nucleus as the rendering engine, containing the blueprints for how the page should display, and the mitochondria as the JavaScript engine, powering our everyday interactions. (Fun fact: mitochondria used to be standalone cells at one point, too, and they even carry their own DNA!)
And you know what? Another way browsers are like living things is that they evolve.
Browser evolution
Back when the first browsers came out, it was a simpler time. CSS was considered the hot new thing when it first appeared in Microsoft Internet Explorer 3 in 1996! There were far fewer JavaScript APIs and CSS specifications to implement than there are today. Over the years, browser codebases have grown to support the number of new features users and developers require to build modern web experiences. It is a delicate evolution between user needs, browser engineering effort, and specification standardization processes.
We have three major lineages of engines right now:
WebKit and Blink (Blink originally being a fork of WebKit) running Safari, Chrome, and Opera
Gecko running Firefox
EdgeHTML (a fork of Trident, aka MSHTML) running Microsoft Edge
Each is very different and has different strengths and weaknesses. Each could pull the Web in a different direction alone: Firefox’s engine has multithreaded processing for rendering blazing fast graphics. Edge’s engine has the least abstraction from the operating system, giving it more direct access to system resources—but making it a Windows-only browser engine as a result. And Chrome’s Blink has the most web developers testing for it. (I’ll get back to why this is a „feature” in a little bit.)
Remember all those Chromium-based browsers we talked about? Well, none of these browsers have to build their rendering engine or JavaScript engines from scratch: they just piggy-back off of Blink. And if there are new features they need? They can develop those features and keep them to themselves, or they can share those features back “upstream” to become a part of the core engine for other browsers to use. (This process is often fraught with politics and logistics—”contributing back” is easier said than done!)
It is hard to imagine any one entity justifying the hours and expense it would take to spin up a browser engine from scratch today. Even the current three engine families are evolutions of engines that were there from the very start of the Internet. They’ve evolved piecemeal alongside us, growing to meet our needs.
Right now, the vast majority of traffic on the Web is happening on Chrome, iOS Safari, or some other permutation of Blink or WebKit.
Branches, renovations, and gut jobs
Some developers would say that WebKit and Blink were forked so long ago that the two are practically completely different browser engines now, no longer able to share contributions. That may be true to a point. But while a common chimney swift and a ruby-throated hummingbird are completely different animals in comparison to each other, when compared to the other animal families, they are still very much birds. Neither’s immediate offspring are likely to manifest teeth, hands, or tails in the near future. Neither WebKit nor Blink have the processing features that Gecko and EdgeHTML have been building up to for years.
Other developers might point out that Microsoft Edge is supposedly a „complete rewrite” of Internet Explorer. But the difference between a „complete gut job” and a mere „renovation” can be a matter of perspective. EdgeHTML is a fork of Internet Explorer’s Trident engine, and it still carries much of Trident’s backlog with it.
Browser extinction
So these are the three browser engines we have: WebKit/Blink, Gecko, and EdgeHTML. We are unlikely to get any brand new bloodlines in the foreseeable future. This is it.
If we lose one of those browser engines, we lose its lineage, every permutation of that engine that would follow, and the unique takes on the Web it could allow for.
And it’s not likely to be replaced.
Imagine a planet populated only by hummingbirds, dolphins, and horses. Say all the dolphins died out. In the far, far future, hummingbirds or horses could evolve into something that could swim in the ocean like a dolphin. Indeed, ichthyosaurs in the era of dinosaurs looked much like dolphins. But that creature would be very different from a true dolphin: even ichthyosaurs never developed echolocation. We would wait a very long time (possibly forever) for a bloodline to evolve the traits we already have present in other bloodlines today. So, why is it ok to stand by or even encourage the extinction of one of these valuable, unique lineages?
We have already lost one.
We used to have four major rendering engines, but Opera halted development of its own rendering engine Presto before adopting Blink.
Three left. Spend them wisely.
By our powers combined…
Some folks feel that if a browser like Microsoft Edge ran on Blink, then Microsoft’s engineers could help build a better Blink, contributing new features upstream for all other Chromium browsers to benefit from. This sounds sensible, right?
But remember Blink was forked from WebKit. Now there are WebKit contributors and Blink contributors, and their contributions don’t port one to one. It’s not unlikely that a company like Microsoft would, much like Samsung and Occulus, want to do things with the engine differently from Google. And if those differences are not aligned, the company will work on a parallel codebase and not contribute that work upstream. We end up with a WebKit and a Blink—but without the deep differentiation that comes from having a codebase that has been growing with the Internet for decades.
It’s is a nice idea in theory. But in practice, we end up in a similar pickle—and with less „genetic variety” in our ecosystem of browser engines.
Competition is about growing, not „winning”
I’m a fan of competition. Competing with other cartoonists to make better comics and reach a larger audience got me to where I am today. (True story: got my start building websites as a cartoonist building her own community site, newsletter, and shopping cart.) I like to remind people that competition isn’t about annihilating your competitors. If you did, you’d stagnate and lose your audience: see also Internet Explorer 6.
Internet Explorer 6 was an amazing browser when it came out: performant enough to really deliver on features previous versions of Internet Explorer introduced like the DOM, data-binding, and asynchronous JavaScript. It’s rival, Netscape Navigator, couldn’t compete and crumbled into dust (only to have its engine, Gecko, rewritten from scratch—it was that small!—by the Mozilla Foundation to be reborn as Firefox later).
Thinking it had Won the Internet, Microsoft turned its attention to other fronts, and Internet Explorer didn’t advance much. When the iPhone came, Apple focused on its profitable apps marketplace and cut efforts to support Flash—the Web’s most app-like interaction platform. Apps gave content creators a way to monetize their efforts with something other than an advertising model. Advertising being Google’s bread and butter, the Big G grew concerned as the threat of a walled garden of apps only using the Internet for data plumbing loomed. Microsoft, meanwhile, was preoccupied with building its own mobile OS. So Google did two things: Android and Chrome.
Chrome promised a better, faster browsing experience. It was barebones, but Google even went all out and got famous (in my circles at least) cartoonist Scott McCloud to make a comic explaining the browser’s mission to users. With Chrome’s omnipresence on every operating system and Android phone, its dev tools modeled off Firefox’s beloved Firebug extension, and increasing involvement in specs, Chrome not only shook Internet Explorer out of its slumber, it was damn near threatening to kill off every other browser engine on the planet!
Pruning the great family tree of browsers (or collection of bushes as it were) down to a single branch smacks of fragile monoculture. Monocultures are easily disrupted by environmental and ecological challenges—by market and demographic changes. What happens when the next threat to the Web rears its head, but we don’t have Firefox’s multithreading? Or Microsoft Edge’s system integration? Will we be able to iterate fast enough without them? Or will we look to the Chrome developers to do something and pray that they have not grown stagnant as Google turned, like Microsoft did, to attend to other matters after „winning the Web.”
It is ironic that the browser Google built to keep the Web from losing to the apps model is itself monopolizing web development much the same way Internet Explorer 6 did.
It’s good to be king (of the jungle)
I promised I’d get back to „user base size as a feature.” Having the vast majority of the web development community building and testing for your platform is a major competitive advantage. First off, you’re guaranteed that most sites are going to work perfectly in your browser—you won’t have to spend so much time and effort tapping Fortune 500 sites on the shoulder about this One Weird Bug that is causing all their internal users to switch to your competitor browser and never come back. A downward spiral of fewer users leading to less developer testing leading to fewer users begins that is hard to shake.
It also makes it much easier to propose new specifications that serve your parent company’s goals (which may or may not serve the web community’s goals) and have that large community of developers build to your implementation first without having to wait for other browsers to catch up. If a smaller browser proposes a spec that no one notices and you pick it up when you need it, people will remember it as being your effort, continuing to build your mindshare whether intentionally or not.
This creates downward pressure on the competition, which simply doesn’t have or cannot use the same resources the biggest browser team has at its disposal. It’s a brutally efficient method, whether by design or accident.
Is it virtuous? At the individual contributor level, yes. Is it a vicious cycle by which companies have driven their competition to extinction by forcing them to spend limited resources to catch up? Also yes. And having legions of people building for just your platform helps.
All the awesome, well-meaning, genuinely good-hearted people involved—from the Chrome team to web developers—can throw their hands up and legitimately say, “I was just trying to build the Web forward!” while contributing to further a corporate monopoly.
Chrome has the most resources and leads the pack in building the Web forward to the point that we can’t be sure if we’re building the Web we want… or the Web Google wants.
Speculative biology
There was a time when Microsoft bailed out Apple as it was about to sink. This was not because Bill Gates and Steve Jobs were friends—no, Microsoft needed Apple to succeed so there would still be operating system competition. (No business wants to be seen as a monopoly!)
But consider, for a moment, that Apple had died. What would personal computers be like today if we’d only had Linux and Windows left standing? What would mobile computing look like if Apple hadn’t been around to work on the iPhone?
Yes, it’s easier to develop and test in only one browser. I’m sure IT professionals would have loved to only support one kind of machine. But variety creates opportunity for us as developers in the long run. Microsoft saving Apple lead to apps which challenged the Web which gave us Chrome and the myriad of APIs Google is charging ahead with. If at any point in this chain of events someone had said, „Meh, it’s so much easier if we all use the same thing,” we wouldn’t have the careers—or the world—that we have now.
Develop in more than one browser. Test in more than one browser. Use more than one browser.
You are both consumer and producer. You have a say in how the future plays out.
I love a good conference that exists because there is a rising tide in technology. JAMstack_conf:
Static site generators, serverless architectures, and powerful APIs are giving front-end teams fullstack capabilities — without the pain of owning infrastructure. It’s a new approach called the JAMstack.
I’ll be speaking at it! I’ve been pretty interested in all this and trying to learn and document as much as I can.
React encourages developers to build by breaking a UI up into components. This means there will always be a need to pass data from one component to another — more specifically, from parent to child component — since we’re stitching them together and they rely on one another.
React calls the data passed between components props and we’re going to look into those in great detail. And, since we’re talking about props, any post on the topic would be incomplete without looking at PropTypes because they ensure that components are passing the right data needed for the job.
With that, let’s unpack these essential but loaded terms together.
Props: The data being passed around
Basically, props are what make React the tool that it is. React was designed to break things down into pieces that are served when they are needed. Props are defining characteristics stored by those pieces and they are accessed and sent when they’re requested. The result is a screen that renders only what it needs and nothing more, speeding up page loads and boosting overall performance.
These data can come in different forms: namely, strings, array and functions. The ability to pass data between components, so let’s break down specifically how to access and pass data.
Passing and accessing props
Let’s say we are working on an application that shows a list of interesting demos pulled from CodePen:
We are passing an array of pens as a prop to the PenList (which we’ll create in just a bit). The parent component (PenList) accesses the data (penList), which gets passed as pens props to the child component (Pen).
The PenList component loops through the pens props (props.pens) to return each item as a Pen component. If this was a class component, we would prefix the pens props with this, like this:
The next thing to note is the use of key in the example. A key is a unique identifier we can assign to each item in our list to make sure we can distinguish between items. In this case, we’re mapping the key to the URL of each pen. There’s no chance of two items being the same, so it’s a good piece of data to use for this purpose.
The remaining properties are passed as props to the Pen component. Here’s the Pen component making use of those props:
Note that we are constructing the Pen component (const Pen) rather than defining it as a class (class PenList) like we did for the PenList component. As such, we can access the values using props. That’s a handy little shorthand we can use instead of re-mapping Pen to the data. The parent already has it, so let’s just pass it along!
Passing functions using props
We just looked at passing an array of data as props from one component to another, but what if we’re working with functions instead? React allows us to pass functions between components, but it’s quite technical. Still, it’s something you’d want to do for specific use cases and worth us looking into.
Let’s use a simple example, say an app that allows you to create a list of tasks. You know, a to-do list, like for chores, projects or what have you. In this app, the list of tasks is contained in the App component, which is the parent component. The Todo component will be the child in this scenario, and its sole job will be to list each task that gets created.
In true to-do list form, we don’t just want to create tasks, but be able to remove them once a task has been created. Since the to-do list is contained in the App component, we have to be able to identify the specific item the user wants to remove from the list by obtaining the id and then remove the item in the App component.
Notice that we defined todoCounter at the top and set it to 1. We created this so we can have unique keys for the to-do items just like we did when we used URLs for the list of pens in our previous example.
The method for deleting tasks is created in the App component. In the render() function, we pass the to-do properties as props to the Todo component. We also pass the handleRemove() function as a prop named removeTodo(). We will use this in the Todo component which looks like this.
class Todo extends React.Component {
deleteTodo = id => {
this.props.removeTodo(id);
};
render() {
return (
<div>
{this.props.value}
<button onClick={() => this.deleteTodo(this.props.id)}>X</button>
</div>
);
}
}
We have to pass the id of the to-do item to removeTodo() in the Todo component because we cannot update the state of the App component without it. This is essentially how we are able to pass a function between components using props — pretty similar to how we did it with an array, the difference being we’re passing functionality around instead of raw data.
PropTypes
PropTypes ensure that the right type of props is passed to a component — and, conversely, that the receiving component is receiving the right type of props.
We can think about them like a football quarterback passing the ball to a receiver. The quarterback only wants his players to receive the ball. And, for that matter, the quarterback wants the receiver to catch a ball — not a cat, pickle or taxi. PropTypes would ensure that the correct object (a ball) is being passed and that it is passed to the correct receiver (player on the team).
(If only football had PropTypes in real life!)
To make use of PropTypes, you have to add the package as a dependency to your application by running yarn add prop-types in the command line.
We can use PropTypes in our app that displays interesting pens. Here is how we will use it for the Pen component:
With this, the language prop will always have a value when it used — even if one isn’t provided.
Wrap Up
Well, that’s a broad look at props in React. It’s pretty much a guarantee that you will use both props and propTypes in a React application. Hopefully this post shows just how important they are to React as a whole because, without them, we have nothing to pass between components when interactions happen. They’re very much a core part of the component-driven and state management architecture that React is designed around.
And propTypes are an added bonus — like a built-in quality assurance checker for catching bugs and letting us know about them. Nice to know that they’ve got our back as we work.
Firefox 62 is shipping out of beta on September 5th. The big notable thing for CSS developers is that it will now support the shape-outside property with polygon(), circle(), and ellipse(), joining Chrome and Safari.
What will be nice about the Firefox release (well, it’s kinda already nice if you use something like Firefox Developer Edition which is already on 62), is that it has a shape editor built right into DevTools.
Chrome supports shape-outside as well, but there is no native DevTools helper for working with them. Thankfully, Razvan Caliman has a Chrome Plugin that does a great job. (Razvan contributed to the Firefox version as well, I hear.)
I enjoy using shape-outside as it can add real visual interest to a page that isn’t nearly overdone or trendy just yet. Plus, in a lot of cases, it doesn’t matter whether it’s supported because the float behaves as a rectangle. If it causes major issues, you can wrap things in an @supports block and do something different.
@supports (shape-outside: circle(50%)) {
img {
/* Only round the image if we can float around it too, otherwise leave it square. */
shape-outside: circle(50%);
border-radius: 50%;
}
}
I do have a few gripes with both the Firefox DevTools and the Chrome plugin though…
I wish it was easier to add a newshape-outside to an existing element. You can do it, but you have to manually add something like shape-outside: polygon(0 0, 10px 0, 20px 0); or something to the element to kick off the tool, then start using it.
I wish they worked with % by default instead of px units.
That second one particularly. It’s so common we size things flexibly these days that hard pixel values are sometimes useless and difficult to convert to flexible percentages.
You’re probably better off starting with Bennett Feely’s Clippy (it’s technically for clip-path, but it includes polygon() it works works for either. It works with percentages, so great, moving on from there.
„The frustrations of using CSS Shapes and CSS Exclusions”
That’s what Ben Frain recently blogged and it has some good points about all this. One key point is that using shape-outside doesn’t necessarily mean that you’re clipping the background. Personally, I find that I’m cutting a shape on backgrounds that are transparent anyway, but I take the point.
To fix this you’ll need a clip-path as well.
The other big one is there is no shape-inside() property (yet), so if you’re hoping to put some text inside a shape rather than have it wrap around the outside of a shape, no luck yet.
Note the double-colon ::before versus the single-colon :before. Which one is correct?
Technically, the correct answer is ::before. But that doesn’t mean you should automatically use it.
The situation is that:
double-colon selectors are pseudo-elements.
single-colon selectors are pseudo-selectors.
::before is definitely a pseudo-element, so it should use the double colon.
The distinction between a pseudo-element and pseudo-selector is already confusing. Fortunately, ::after and ::before are fairly straightforward. They literally add something new to the page, an element.
But something like ::first-letter is also a pseudo-element. The way I reason that out in my brain is that it’s selecting a part of something in which there is no existing HTML element for. There is no <span> around that first letter you’re targeting, so that first letter is almost like a new element you’re adding on the page. That differs from pseudo-selectors which are selecting things that already exist, like the :nth-child(2) or whatever.
Even though ::before is a pseudo-element and a double-colon is the correct way to use pseudo-elements, should you?
There is an argument that perhaps you should use :before, which goes like this:
Internet Explorer 8 and below only supported :before, not ::before
All modern browsers support it both ways, since tons of sites use :before and browsers really value backwards compatibility.
Hey it’s one less character as a bonus.
I’ve heard people say that they have a CSS linter that requires (or automates) them to be single-colon. Personally, I’m OK with people doing that. Seems fine. I’d value consistency over which way you choose to go.
On the flip side, there’s an argument for going with ::before that goes like this:
Single-colon pseudo-elements were a mistake. There will never be any more pseudo-elements with a single-colon.
If you have the distinction straight in your mind, might as well train your fingers to do it right.
This is already confusing enough, so let’s just follow the correctly specced way.
I’ve got my linter set up to force me to do double-colons. I don’t support Internet Explorer 8 anyway and it feels good to be doing things the „right” way.
WooCommerce is a powerful eCommerce solution for WordPress sites. If you’re like me, and like working with WordPress and have WordPress-powered sites already, WooCommerce is a no-brainer for helping you sell things online on those sites. But even if you don’t already have a WordPress site, WooCommerce is so good I think it would make sense to spin up a WordPress site so you could use it for your eCommerce solution.
Personally, I’ve used WooCommerce a number of times to sell things. Most recently, I’ve used it to sell T-Shirts (and hats) over on CodePen. We use WordPress already to power our blog, documentation, and podcast. Makes perfect sense to use WordPress for the store as well!
What I think is notable about our WooCommerce installation at CodePen is how painless it was, while doing everything we need it to do. I’d say it was a half-day job with maybe a half-day of maintenance every few months, partially based on us wanting to change something.
The first step is installing the plugin, and immediately you get a Products post type you can use to add new products. We’re selling a T-Shirt, so that looks like this:
Note the variations in use for size. We even track inventory at the size level so our T-Shirt printing company knows when to re-print different sizes.
What is somewhat astounding about WooCommerce is that you might need to do very little else. You could set a price, flip on the basic PayPal integration and enter your email, publish the product, and start taking orders.
Or, you could start customizing things and do as much or as little as you want:
You could add as many different payment processors as you like. We like using Stripe for credit card processing at CodePen, but also offer PayPal.
You could customize the template of every different page involved, or just use the defaults. At CodePen we have very lightly customized templates for the store homepage and product page.
You could get very detailed with calculating shipping costs, or use flat rates. We use a flat rate shipping cost at CodePen almost as marketing: same shipping cost anywhere in the world!
You could get into integrations, like connecting it with your MailChimp account for further email marketing or Slack account to notify your team of sales.
If you can dream it, you can do it with WooCommerce.
At CodePen, we work with a company called RealThread that actually prints and ships the T-Shirts.
They work great with WooCommerce of course, and the way we set that up is that we use the ShipStationintegration and blast the orders into their account there and they handle all the fulfillment from there. There are all sorts of shipping method plugins though for anything you can think of.
Within WooCommerce, we have a dashboard of all the orders, their status, and even tracking information should we need to look something up.
So essentially:
We use WooCommerce
We use the Stripe plugin to take our credit card payments that way
We use the PayPal plugin to take PayPal payments over Braintree
We use the ShipStation plugin to send orders to that system for our fulfillment company to handle
It was quite easy to set up and works great, and it’s comforting to know that we could do tons more with it if we needed to and support is there to help.
Note the double-colon ::before versus the single-colon :before. Which one is correct?
Technically, the correct answer is ::before. But that doesn’t mean you should automatically use it.
The situation is that:
double-colon selectors are pseudo-elements.
single-colon selectors are pseudo-selectors.
::before is definitely a pseudo-element, so it should use the double colon.
The distinction between a pseudo-element and pseudo-selector is already confusing. Fortunately, ::after and ::before are fairly straightforward. They literally add something new to the page, an element.
But something like ::first-letter is also a pseudo-element. The way I reason that out in my brain is that it’s selecting a part of something in which there is no existing HTML element for. There is no <span> around that first letter you’re targeting, so that first letter is almost like a new element you’re adding on the page. That differs from pseudo-selectors which are selecting things that already exist, like the :nth-child(2) or whatever.
Even though ::before is a pseudo-element and a double-colon is the correct way to use pseudo-elements, should you?
There is an argument that perhaps you should use :before, which goes like this:
Internet Explorer 8 and below only supported :before, not ::before
All modern browsers support it both ways, since tons of sites use :before and browsers really value backwards compatibility.
Hey it’s one less character as a bonus.
I’ve heard people say that they have a CSS linter that requires (or automates) them to be single-colon. Personally, I’m OK with people doing that. Seems fine. I’d value consistency over which way you choose to go.
On the flip side, there’s an argument for going with ::before that goes like this:
Single-colon pseudo-elements were a mistake. There will never be any more pseudo-elements with a single-colon.
If you have the distinction straight in your mind, might as well train your fingers to do it right.
This is already confusing enough, so let’s just follow the correctly specced way.
I’ve got my linter set up to force me to do double-colons. I don’t support Internet Explorer 8 anyway and it feels good to be doing things the „right” way.
