Yesterday, while at a workshop, React Hooks (intro here) became the subject of discussion between participants. Someone in the audience asked how to easily map the classes+lifecycle way of thinking onto hooks, as she had trouble doing so.
In short, my recommendation was to no longer think in lifecycles but to think in effects, as useEffect was created for exactly this type of thing: when one (state) value changes something else should happen. It also provides you with cleanup methods, to perform stuff one would typically do in componentWillUnmount.
When coming home later that day I was really glad to see that Sebastian had just published a blogpost, along with a practical example, on that very same subject:
React recently introduced a new way to deal with side effects: the useEffect hook. Translating lifecycle methods to useEffect calls can be confusing at first. It’s confusing because we shouldn’t be translating imperative lifecycle methods to declarative useEffect calls in the first place.
Thanks for writing this post Seb, saved me some time from writing it myself 😉
Despite being over 20 years old, there’s signs that CSS might be going through the same tumultuous teenage years that JavaScript just went through. Flexbox! Grid! CSS-in-JS! In 2019, CSS is finally dyeing its hair pink and getting a tattoo just like it’s always secretly wanted.
Parenting books won’t help much with this one, but that’s where we come in: we’ve surveyed over 10,000 developers in this first ever State of CSS survey. So join us to find out which CSS features are used the most, which tools are gaining adoption, and much more.
Using the “Awareness – Interest – Satisfaction” ratio rankings, you can verify (or adapt) your choices.
This typehint would tell PHP that you require a variable to be “an array of Foo‘s”. With the current typehint system that not possible: when requiring the type array, you cannot specify its contents.
And no, the variadic function syntax is not a closing solution workaround for this.
At the City Intelligence unit at City Hall almost anyone can create a data visualisation. To keep everyone in line they created Data Design Guidelines:
Effective communication of evidence and data through information design and data visualisation, is obviously important to help inform policy internally, but it is also just as important to help boroughs and individual Londoners better understand their city.
With this in mind, over the past year, we have been thinking more about how we can improve the clarity, consistency and accessibility of our data visualisation output.
The guidelines, which focus principally on chart design, cover the following areas:
As seen at the most recent CSS Day. I’m quite sure this will help many developers to make their POCs/experiments visually more interesting:
Sometimes when we look at a polished interface we can acknowledge that it looks good but it’s hard to articulate why it looks good. In this practical session, Steve will be explaining the why. He’ll be looking at a poorly designed UI and refactoring it while providing some of the strategies and techniques designers use to give an interface that polished look.
We’ll be looking at some of the more common problems faced by designers and developers—from simple forms to complex data—showing what a difference a few small cosmetic changes can do to bring design to the next level.
I know many designers will shrug when seeing this, but keep in mind that it’s intended for developers to make sure their POCs and demos look “good enough”. The guidelines/changes are simple, and make a huge difference … I wish my students from back in the day had seen this video.
About two months ago I developed the website for vBridge, a new company I’m participating in. As the website consists of only one static placeholder-like page, I decided to look into hosting the page directly onto a CDN. Having heard a lot of good things about Netlify, I decided to check that out.
The site itself is built from its source through Webpack by calling yarn build. Where I’d normally go for an external build service to build the site for me, and then deploy it from there into a bucket onto Google Cloud Storage or Amazon S3, Netlify allows me to remove this extra service in between as it has built-in support to building the source for me:
And best of all? Netlify is free(for basic sites), and supports Lambda Functions, and is configurable through a file named netlify.toml.
Configuring Netlify trough netlify.toml
Before adding the site to Netlify itself, I added an instruction file named netlify.toml in the root of the repo. This file tells Netlify what the build command is, which folder needs to be deployed, which redirects to perform, etc.
Here’s the full contents of my netlify.toml configuration file:
[build]
publish = "build"
command = "yarn build"
[[redirects]]
from = "https://vbridge.netlify.com/*"
to = "https://www.vbridge.eu/:splat"
status = 301
force = true
[[headers]]
for = "/*"
[headers.values]
X-Frame-Options = "DENY"
X-XSS-Protection = "1; mode=block"
Referrer-Policy = "no-referrer"
X-Content-Type-Options = "nosniff"
Strict-Transport-Security = "max-age=63072000; includeSubDomains; preload"
Let’s break that down into several pieces:
[build]
publish = "build"
command = "yarn build"
This snippet tells Netlify what the build command is (yarn build), and which folder that needs to be deployed (build).
[[redirects]]
from = "https://projectname.netlify.com/*"
to = "https://www.domain.tld/:splat"
status = 301
force = true
Whenever you deploy a project to Netlify, it will deploy it to a projectname.netlify.com subdomain. To prevent people from accessing the site through that subdomain, add this redirect instruction to your netlify.toml. The snippet is smart enough to retain the value of the pathname when redirecting
After having added the netlify.toml into the repo, one still needs to:
Add the project to Netlify itself (see the video above)
As your own domain is not pointing to Netlify yet, you might want to skip on that [[redirect]] part in your netlify.toml for now …
Update DNS so that your own domain points to the Netlify servers (ref)
Add/change CNAME record for www and point it to projectname.netlify.com.
Set A record to 104.198.14.52, or if your DNS provider supports CNAME Flattening, ANAME, or ALIAS, alias the root domain to projectname.netlify.com.
Once DNS has propagated, Netlify will automatically enable HTTPS for your site: Netlify will automatically redirect non-https and non-www visits to https://www.domain.tld/
The Strict-Transport-Security header in my netlify.toml is a recommended extra on top of this, intended for browsers. By adding this, browsers will immediately request the site over HTTPS, even when the user types in http://… first. See MDN’s page on HSTS for more info.
And oh, if you want to create your own 404 page, just build a file named 404.html and it will be used as the 404 page 🙂
Did this help you out? Like what you see? Consider donating.
I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!
Recently the Google Street View footage for the area I live in got updated. This got me thinking: Google Street View is a time capsule. I’m quite sure that one day we’ll be able to time travel through the captured footage.
GooBing Detroit is a project compares old and new GSV footage from the Detroit Area:
As just announced (on stage) at CSS Day by Heydon himself:
If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.
Employing algorithmic layout design means doing away with @media breakpoints, “magic numbers”, and other hacks, to create context-independent layout components. Your future design systems will be more consistent, terser in code, and more malleable in the hands of your users and their devices.
