Forem: Wei Gao

Animated CSS Blob

Wei Gao — Thu, 07 Jan 2021 10:56:14 +0000

I'm a pure blob over the holidays these days, so I decided to make something blobby on my website.

Here is this blob:

There are quite a few ways you can create blobs on the web. But following the blobby attitude I've chosen the simplest technology – CSS border radius – one that I can wrap my brain around with, to be the main recipe for this blob. Overall, it'll still be a few simple techniques put together that I'll briefly list out in this post.

CSS border radius

The key to the irregular shape is to make use of the power of border radius. Not only can you specify each corner, but also you can supply pairs of values such that each corner can take different border radii so that it looks skewed towards one direction or the other.

Here's a video showing its mechanism from Robin Rendle's post:

The video is taken from fancy-border-radius that you can use to play around with the shape defined by those border radii.

Generally speaking, the smaller the percentage value, the sharper it will look at the point the blob touches its bounding box. I want my blob to look fairly rounded so I've taken fairly large values in those radii. And to get the curves to have a smooth join, it's worth to make the percentage values complement to each other in pairs – and fewer random numbers needed to generate as well.

Animation

I've used simple keyframes for the animation. My blob is quite slow, it's 7s animation on alternate direction & infinite loop. I've also made them spin a little bit by adding a transform: rotate() to the animation frames.

Also, to add some randomness I've generated the animation when component mounts.

Blending

As you can see, the blobs created by CSS border radius will be all convex, the shape a bit simple. To add some flavor to it, I've recalled my mix-blend-mode magic (you can read about it in my other post about CSS mix-blend-mode). Namely, I've created three blobs with slightly different shades of grey and some offset in their animation-delay, and made them mix-blend-mode: luminosity with one another.

When you enlarge them they look pretty sick, I think:

Putting them altogether, here's one of the generated animation CSS:

.blob {
  animation-name: blobby;
  animation-duration: 7s;
  animation-iteration-count: infinite;
  animation-timing-function: ease;
  animation-direction: alternate;
  mix-blend-mode: luminosity;
}
@keyframes blobby {
  0% {
    border-radius: 50%;
  }
  20% {
    border-radius: 41% 59% 41% 59% / 53% 51% 49% 47%;
    transform: rotate(36deg);
  }
  40% {
    transform: rotate(72deg);
    border-radius: 43% 57% 41% 59% / 53% 52% 48% 47%;
  }
  80% {
    border-radius: 48% 52% 41% 59% / 48% 58% 42% 52%;
    transform: rotate(108deg);
  }
  100% {
    transform: rotate(144deg);
    border-radius: 54% 46% 60% 40% / 43% 55% 45% 57%;
  }
}

There are a few more CSS properties such as each of the blobs' color and animation-delay, you can inspect them in my site here.

Rethinking React Knowledgeable

Wei Gao — Tue, 06 Oct 2020 14:44:23 +0000

Last week marks the second full year for me and Ken Lee to have run React Knowledgeable, for Shopee and the local developer community combined. Altogether we have 85 weeks at the back of our memory. And, unexpectedly or not, at this two year mark, we've decided to change it to something completely different, project code rk-next.

There are a few causes that could seem quite obvious:

the conference / meetup scene is significantly disturbed by the COVID-19 situation this year
as most of us are working from home semi-regularly, we interact with each other much less that used to inspire many thoughts and ideas for sharing
this could be personal but I feel it is overall more stressful to work from home and alone, and therefore less willing to prepare a sharing

Although, if only for the reasons above, there are ways other than a radical reform to adapt to the situation. For example, we could fallback to the luckydraw system. Or, we could drop the frequency. We could even pause for longer until things start to recuperate.

But, there are also a few more reasons that pushed me to rethink RK at this time:

Now that we have a much larger team, how much participation does each of us get, if we continue to run it as a weekly sharing where 1 person gets the podium? And more practically, do myself and Ken have enough capacity to run it, if we keep scaling it up?

What do we really want to get out of a weekly sharing? What do we want on a deeper level? Can RK help the true cause in any other format that fits the current situation better?

Rethinking RK

At this two-year mark, I'll share those questions I've been thinking of for the past two months, and invite those of you who are in the loop of RK, to join me for a bit of discussion on what we just started recently -- RK in Rosters, where we break into small and private groups, and commit to the roster for a fixed period of time. The rosters are proposed and run by some of us who will take the lead and say, "let's do this." Despite how semi-well-thought-of it seems right now, please still question it, experiment with it, and most importantly, feel if and how you'd like it to be a part of your weekly routine, at least for the time being. Exactly like two years ago we're creating something completely original of our own, and so everyone of us may take a part of it and have the power of shaping it to something you want.

Do we want to keep scaling up like a conference, or do we want a smaller learning group?

This is a pseudo question. The RK in Roster proposal is our answer to this question already, but let me still share why.

The moment I realize our audience size as it is intended for, it was a near instant signal that we need something different. Before we even called it RK, the best team weekly I had been part of was the "this week I learned" section that used to occupy the current RK hour, for:

it was the most relaxing hour of the week
we were comfortable with one another in the team
it was a very good recap of the week, a raincheck that we're learning, an opportunity to revisit the problem and sharpen the understanding

Now that our audience size is reaching a mini conference, it deviates so far away from the original, cozy, relaxed and content-focused sharing podium, that I had to re-start the same initiative within a 4-person team that I had the brief fortune to lead, for the past few months. Then, as one of the organizers for RK I'd ask, can I bring the similar experience back?

Should it be topic-based or people-based?

I've been with Shopee for close to 4 years now. There are many people who I have worked with and enjoyed the accompany with. The 6 people in my original team are working in different teams / groups now. But I still want to be in close proximity with them and would like to occasionally catch up to see what each other is working on.

I find RK fits a right scope for the right time for this. Developers from our few front end teams don't work with each other on a daily basis. Within RK's scope, but cross each of our feature line teams and groups, why don't we give our ourselves a cause to regularly and semi-casually catch up with one another, especially with those who we don't directly work with, and together work on or share front end things.

That's why, at the back of my mind, I really want people to group up based on who you enjoy the talking with. It's a mindset shift. I observe that now people are hosting and joining groups mainly based on topics. They're very attractive, especially before we know each other so well to have some blind faith, topics are the only tangible cause for people to decide to join. On the flip side, I really want to propose that we run some more relaxed, people-based groups that don't set a specific topic. We come in and see what other people are working on lately and let ideas flow.

Some of the rosters now are assignment-based. They're very interesting. We send out a goal / assignment at the beginning of each week, and we find our own time to explore a bit about it, and we come back at the end of the week for a discussion. In essence it's still based on a topic but we call for more participation by inviting you to work on something.

What's your preference?

What's the learning process that RK should highlight?

Learning and exploring is a popular initiative in our industry. But to me and my perspectives on RK, I think the learning process should not narrowly focus on the mere intake of new technology from other people.

The Shopee app that we are collectively building has many enough questions to push us to see how other people are solving similar problems, decide whether they will solve our problems, and come up with our own solutions when necessary. This sometimes is happening on a very significant level, like some of us are building some very complex systems to make pieces of our code function together. But note that it certainly happens on a micro level and the major renovation is an iterative process of explorations, trials and errors, asking questions, asking better questions, attempting to answer them, and revisiting and recapitulating.

function iterate() {
  explore();
  trialAndError();
  askQuestion();
  try {
    answerQuestion();
  } catch {
    console.log('oops, wrong liao');
  }
  recapitulate();
  iterate();
}

Previously, RK participates at the very end of this process. After you learned something, we encourage you to share your thoughts. Today, RK takes a step forward and invites you to take part of this messy, uncertain, and only sometimes rewarding process, one where we urge you to bake into your weekly routine to look back and see if you've put your minds on something worth mentioning, even just to yourself, over the past week.

How it works

We host RK in Rosters in terms of 8 weeks. Each term, you may either host or join a roster. We will intermittently run one or two community events when we invite everyone back for a to share our progresses thoughts, and we go back to the regular term sessions.

What RK asks of you

There are only two things that we (sort of) require that you do:

One, participate non trivially. In the old RK, speakers prepare sharing topics and audiences sit back and listen. This is not interesting (enough), if you haven't realized, by giving a sharing yourself.

Two, commit to your same group of people for the whole duration of each term.

And in return, RK allows you to switch around with no strings attached, by running all rosters in terms of 8 weeks. If there's anything you don't enjoy, you realize you hate someone, etc., note that it'll end in 8 weeks. And if you really enjoy what your roster is doing, great, you can make it happen again in the next term.

What this really is

...is that we are developers who love to explore, and among us a few would like to take the responsibilities to lead a direction. RK sets the game rule, but it's pointless if not for the hosts who will lead the experience, and for the participants who find it meaningful.

FAQs

If I host a roster, does that mean I forever cannot join other rosters?

You can choose to host your rosters at alternating terms. Or, you can help someone in your roster to become a future host :)

I'm really interested in this topic, but I am unsure about the commitment it takes to join

Please don't let this stop you from joining. We understand that each of us has work commitments that should take priorities and the roster hosts won't judge you for not making progresses on occasional weeks.

Will there be a roster on X?

Please start one :) We'll help you get started with hosting

Will there be no regular RKs anymore T_T?

We'll host joint events at a longer interval, monthly or every two months.

Will joint events take only roster sharing topic?

No, please still submit sharing if you have anything outside of your roster (or if you're not in any roster) that you want to share.

Is it internal T_T?

For the time being, the Rosters are internal. If you like the idea, there are other initiatives that share some similar thoughts, such as the KCD Learning Clubs (thanks @lihautan for referring). If ours work well, we might see how we can help build similar things in the local community.

The community events will be open to the public.

Play with React Concurrent Mode with Your Gatsby Site [updated with more proper solution]

Wei Gao — Mon, 28 Oct 2019 16:06:43 +0000

So the React team released curious cat version for concurrent mode, and I want to try that with my personal sites and side projects, only to realize that by using Gatsby I do not have direct access to my ReactDOM.render(), which I am supposed to change.

TL;DR

Put in your gatsby-browser.js the following:

Solution by Fredrik Höglund:

// gatsby-browser.js
const ReactDOM = require('react-dom');

exports.replaceHydrateFunction = () => {
  return (element, container, callback) => {
    ReactDOM.createRoot(container, {
      hydrate: true,
      hydrationOptions: { onHydrated: callback },
    }).render(element);
  };
};

Notes

A quick search landed me on this issue, which brings me to Gatsby's Browser APIs. And in particular, its replaceHydrateFunction. This function is meant for customized hydration on SSR. It just so happens that it becomes our chance to swap out the ReactDOM.render() call. Gatsby will call what we return as the replacement.

exports.replaceHydrateFunction = () => {
  return (element, container, callback) => {
    console.log('rendering!');
    ReactDOM.render(element, container, callback);
  };
};

And from React's official docs on Concurrent Mode, this is what we should change:

import ReactDOM from 'react-dom';

// If you previously had:
// ReactDOM.render(<App />, document.getElementById('root'));
// You can opt into Concurrent Mode by writing:

ReactDOM.createRoot(document.getElementById('root')).render(<App />);

My initial attempt was to write my tweak like this:

exports.replaceHydrateFunction = () => {
  return (element, container) => {
    ReactDOM.createRoot(container).render(element);
  };
};

It works. But on local build only. On production build, my page content gets duplicated, as you can see in this preview.

Out of my amateurish understanding around Gatsby, this looks like a DOM hydration issue. I now have a blurry understanding about why this following code works, but I probably should not be misleading people. If anybody has a better understanding, please teach me 🙆🏻‍♀️

I later on realize the problem was probably due to not calling ReactDOM.hydrate, which is supposed to be the default behavior. Below has been updated to some code that works:

exports.replaceHydrateFunction = () => {
  return (element, container, callback) => {
    ReactDOM.hydrate(element, container, callback);
    ReactDOM.createRoot(container).render(
      process.env.NODE_ENV === 'production' ? callback(element) : element
    );
  };
};

But Fredrik Höglund pointed out that this is problematic, because

In legacy mode, ReactDOM.render and ReactDOM.hydrate are two separate functions. In concurrent mode, there is only one function, ReactDOM.createRoot, but with an option for hydrate.
Src if curious

So a more proper fix will be as follows:

exports.replaceHydrateFunction = () => {
  return (element, container, callback) => {
    ReactDOM.createRoot(container, {
      hydrate: true,
      hydrationOptions: { onHydrated: callback },
    }).render(element);
  };
};

And you can check out the twitter discussion.

More notes

Don't read these.

When and how does Gatsby call `render`?

It calls the renderer which is the return of replaceHydrateFunction, defaults to ReactDOM.hydrate. Then, it will call onInitialClientRender, which is the third parameter, callback, in the return function of replaceHydrateFunction.

What does `ReactDOM.hydrate` do in a Gatsby site?

According to the Gatsby documentation on DOM hydration:

hydrate() is a ReactDOM function which is the same as render(), except that instead of generating a new DOM tree and inserting it into the document, it expects that a React DOM already exists with exactly the same structure as the React Model. It therefore descends this tree and attaches the appropriate event listeners to it so that it becomes a live React DOM. Since your HTML was rendered with exactly the same code as you're running in your browser, these will (and have to) match perfectly.

Checking our Gatsby site's public directory, those are some uglified HTMLs.

The hydration occurs on the <div id="___gatsby">...</div> element defined in default-html.js.

But I still don't understand what caused the duplication above -.- It duplicates the child element of <div id="___gatsby">...</div>.

What happens if the DOM isn't properly hydrated or `onInitialClientRender` isn't properly called?

event handlers don't get attached
css-in-js doesn't get inserted

maybe more

Re-export Context Provider

Wei Gao — Wed, 23 Oct 2019 03:43:44 +0000

Recently I realize I like this pattern a lot, much enough that I'll write a short note on this.

Problem

When we use React's Context, we need to first create the context:

export const ContextA = React.createContext(null);

Then <Context.Provider /> is normally called elsewhere. We'd probably import the context, grab the named Provider inside, and mount that <Provider /> with a value that we as a user needs to know. And likely higher in our component tree we have many of these:

const App = () => (
  <PlaylistContext.Provider value={mySpotifyPlaylist}>
    <CoffeeContext.Provider value={!!morning ? 'americano' : 'flatwhite'}>
      <WorkspaceContext.Provider value={code}>
        ...now i can start working
      </WorkspaceContext.Provider>
    </CoffeeContext.Provider>
  </PlaylistContext.Provider>
);

Approach

What makes more sense to me is that the developer who works on the Context probably knows all the things about it. Here is something I learned from Jamie's hook-based Unstated library. Instead of exporting the bare bone Context, we can wrap and re-export the context provider. This allows the author of the context to keep all the logic along the same conceptual object in one place.

export const PlaylistContext = React.createContext(null);

export const PlaylistProvider = ({ children }) => {
  // potentially code to create "value"
  const playlist = ['Bach Cello Suite No.1 in G Major, BWV1007'];
  return (
    <PlaylistContext.Provider value={playlist}>
      {children}
    </PlaylistContext.Provider>
  );
};

Now in our app root, or anywhere we need to use the context, we no longer need to generate and supply that value elsewhere. We can write very terse context providers like this:

const App = () => (
  <PlaylistProvider>
    <CoffeeProvider>
      <WorkspaceProvider>...my day of work</WorkspaceProvider>
    </CoffeeProvider>
  </PlaylistProvider>
);

If you are with TypeScript and have complaints around annotating the context value with a potential null when creating the context, check out this solution in React TypeScript Cheatsheet.

Relevant links

Properly Include Component Function from `useEffect` and `useCallback` Dependency List

Wei Gao — Sun, 13 Oct 2019 06:19:33 +0000

I was working on Slots (letting a portal component render into a potentially not mounted portal home) when initially I was violating a hooks rule. Namely, I did not include the setSlot function I called within the useCallback body inside its dependency list.

export const SlotHome = ({ slotName, className }) => {
  const [, setSlot] = useSlot(slotName)
  const ref = React.useCallback(node => {
    // we're lying to hooks because we're using setSlot without including it in the deps list
    setSlot(node)
  }, [])
  return <div className={className} ref={ref} />
}

But if I do include it, the function is different every time the component render is called and therefore would re-render like a maniac. Without including it, the implementation still works, but we're lying to hooks and it is strongly advised against.

This made me finally decided (cuz it says it's a 49-min read) to read Dan Abramov's article, A Complete Guide to useEffect and decided to properly figure this out. Here are some key takeaways:

class components mutate state
functional components + hooks retain the proper closure behavior (always use closed variable, no mutating crap)
3 ways to optimize dependency list
- remove unnecessary use of params in component lifecycle scope
- use reducer
- memoize functions with useCallback

The highlighted takeaway was what solved this problem. The idea is to tell hooks that the function won't change unless what we specify in that useCallback's dependency list change.

const [, setSlot] = useSlot(slotName)
// specify that setSlotMemo won't change unless slotName changes
const setSlotMemo = React.useCallback(setSlot, [slotName])

// now ref is safe to include setSlotMemo in its deps list
const ref = React.useCallback(
  node => {
    setSlotMemo(node)
  },
  [setSlotMemo]
)

Once again Dan's article covers a complete guide to properly use useEffect (which extends to useCallback because they share the same signature).

Relevant links

4 Years as Front End

Wei Gao — Sat, 12 Oct 2019 14:49:23 +0000

Today (Sept 8, 2019) marks the 4th year anniversary of my working full time as a front end developer. Before this, I've never done anything consistently past two years other than my college major. I also find some interesting alignment with a college life so here's a personal chronicle.

Year 1

In the summer of 2015, I passed the interview to my previous company out of my amateurish knowledge from making webpages since I was a kid. It was the time when jQuery was still a thing but was getting implemented into browser APIs, template based front end frameworks were big, and some early adopters were trying out Vue and React.

One thing that left an impression was my first encounter with Vue. The guy sitting next to me handed me a project that was due on the second day (literally, I don't know how that could even be remotely possible today). He said that the project was set up in Vue and it should be an easy two-hour thing. Did he not know it was my first time using Vue, or anything at all other than jQuery? I forgot how I ended up making everything work and had it delivered.

On a similar note, it was a very immature year for me. I had no methodology, no choices of frameworks, and no tastes at all. I followed whatever that was in the codebase.

I loved the job, though. I enjoyed the playfulness. To me assembling pages from PRD, design specs, and back end API documentation was exactly like playing Lego. And I had a day job getting paid doing that. Can't dream about anything more.

Another aspect of that job was its comprehensiveness. All my projects involved three ends, a consumer-based web app, a business facing PC site, as well as an internal CMS. So I had the opportunity to explore all those platforms, meaning a large aspect of what counts as front end was covered.

One of my "freshman" project had a cute interaction that I liked a lot.

The environment wasn't very promising for technical advancement though. The department did not have much idea where to go. Then at some point of time the whole department shut down. There was some more drama going on and I'm glad I learned early that I'd prefer to steer clear from dramas, disputes, gates and stuff.

Year 2

I joined my current team shortly into my second year. The process was somewhat amusing. I was reading books about JavaScript about half a year into year 1. Pumping up theoretical knowledge gave me a false illusion that I could pass any interview already. Then a recruiter contacted me and asked if I'd like to consider a position based in Singapore and that the interview would be very challenging. I was intrigued both by the relocation as well as wanted to see if my book reading was fruitful or not. So I went with the interview.

The interviewer has the most hatred generating way of interviewing. He asks increasingly difficult problems until beyond what the interviewee can solve, then he tries to see the potential from there. For me it seemed a bit way beyond. Since I could answer probably 2 out of the 7 questions he asked, I thought I had pathetically failed. But he hired me on the basis that I said I liked front end and he believed that as long as you like it, you'd sooner or later become very good.

When I then joined this team, everyone but myself had a CS degree and they were all good to the level I could not evaluate. We were a team of 6 supporting all our web apps across PC and mobile browsers. I started saying that it is the best team I've ever worked with, although I didn't consider myself to be part of it.

It may sound weird but it was also the first time I maintain a codebase with other people. I had to understand other people's code routinely. And I needed to make sure my code is comprehensible.

In college I was very hooked up with a math / cs project called Project Euler, in which ingenius solutions were something you'd be proud of. Then in the beginning of me getting serious about coding, I liked to write very abstractly mathematical code. I remember I once wrote an algorithm that casts two dimensional values into one string for easier computation in binary. My leader didn't agree with it but I insisted. After a while I started to sense the extra burden to carry such solutions and started to appreciate the code nicely said.

I was also picking up React mainly by following other people's code. Writing lifecycle methods for web pages seemed a bit unnatural to me (I still don't like the idea, I feel it's too much of a software engineering thing brought to the web arena). I also didn't understand all the Redux boilerplate and whatever pattern that Redux Saga uses, so I asked the team lead "how did you come up with this", and he said he didn't come up with it, it's "standard". Clearly that's a wrong question to ask but that was where I roughly rounded.

Year 3

I think I have a gist on intuition but am very bad at implementation. And frankly, I didn't know how to improve. So year 3 was a serious doubt on my proficiency at the job. I think there are three levels:

Failing it
No complaint, but nothing great neither
Absolutely beyond expectation

I think there are people born with the right skill set for the subject matter and they enter the field and directly achieve 3 from entry level. Sadly, with software development, I was barely moving away from 1. But that actually wasn't all that bad. I think what is worse is to get stuck at 2.

2 is a phase where you get comfortable with your day-to-day job. I became familiar with our codebase. I could do my job just alright. I sometimes read other people's code and figured there was no way I could write code like that. But I didn't know what I could do to become better.

2 is also the worst phase in a sense that people cannot blame you. You've made no mistakes. There were a few 1-1's that went very badly because my managers were expecting more from me and the way we communicated made me think they were blaming me. I think I ended up crying a few times. I also had a long doubt that since the industry has changed so much from the first time I playfully created web pages (year 2000?), maybe I was making a wrong career choice, it's a different job now.

In my spare time, I developed a catching interest in climbing. Climbing taught me deliberate practice and has made me used to trying out problems that slightly intimidate me. There's great joy if you get a hard problem down, especially if after consistent training and thoughtful planning. In fact it has such a profound impact in me I could no longer be satisfied living my life any other way. I realized I wasn't doing this in my job, then. It was more than boring compared to what I was doing in climbing.

My recent longest bouldering project, took me a good two months to figure out, many gym visits if not more, many more movement exercises in my other trainings. This post is a work in progress missing the last move, the final send is in another post but I tend to like the wip ones better :)

Back to the not-much-to-be-said year 3, it kind of tailed into year 4 with me looking for inspirations by going to a conference.

Year 4

I feel more has happened in year 4 than all previous 3 years combined. I have also gained a little bit of exposure throughout the past year. I normally do not present myself very well as I find little motivation in justifying the things I do. Let results speak for themselves, or so I think. But I guess since more people are willing to hear what I have to say, I entitle myself to share a little bit of what I believe could be the most critical moments for myself.

I met Mark Erikson after React Rally 2018, who had me work on React Redux docs. It's a true gem in learning that I understand only in retrospect. Writing docs puts anybody on the side of "teaching", which requires a completely different level of understanding. The knowledge doesn't flow in automatically, though. You'd still need to dig in the sourcecode yourself. But people play Lego to enjoy the process of assembling them, not to look at the final product right? And so writing docs provides a similar ground for learning in that sense. Meanwhile, Mark has helped me with more than multiple rounds of revisions, from which I've learned a million things about both Redux and React. He has also been promoting the work I've done at all chances for which I am forever grateful about.

I then worked on many more docs, of which some more substantial work includes Docusaurus and our internal manual. I now have a lot of faith in docs. In a simple manner, I'll normally believe in whatever said in the docs myself. Furthermore, if the answer people are looking for is well said in the official docs, it saves their time because they don't need to look elsewhere. So that's a unique golden place to have in mind. For me docs are also the best opportunities to #learnInPublic. Even if a question may already have been answered everywhere, the work and thoughts to organize them into a Q&A entry to fit the context of the official docs is non-trivial. Plus you'd get multiple eyes for revisions, and the outcomes are very valuable (see previous point).

The other thread of year 4 is around React Knowledgeable, a weekly sharing we organize initially in our React team, and now another public section in Singapore. Our thoughts have evolved multiple times around how specifically to run it, but the motivation has remained rather constant – to have a consistent, fun and friendly podium to share what we learn as a React developer. I was once asked to write a few bullet points for the value of its existence and our manager threw out an example that goes "by listening to talks at RK a developer can learn...", and I immediately noticed that that needed to be changed. It is less about the listening part that makes an average developer (me) a slightly better one but the sharing part. At this one year mark more and more of us are starting to realize this, and our podium has become more stablized. We've grown from ~30 to ~40 developers, but that's still a very small group for our 43 weeks of 60+ talks. Two thirds of us have spoken and nearly all spoke multiple times. I find that pretty amazing even today. Some of the talks we have are way beyond expectations for an internal sharing, trully the most brilliant team I've ever had the fortune to be in and I'm really very overly proud of this.

The Singapore chapter of React Knowledgeable is just getting started. I don't know where I obtained the luck to have onboarded a few of the coolest React developers I've ever met. And so RK is shaped up by more cool minds now, calling for attention and caring from a bigger audience, as well as available to more people for grab. The meetup version is different from an internal sharing, and we haven't completely figured out where it rounds. But I think the learning spirits and the fun and friendly podium should stay.

I've had troubles ending this article because I still have a tonne of questions I constantly wonder about. Eventually, I decided that instead of tossing out more of my crude thoughts, I'll refer to senpai's thoughts. My favorite deskmate Kenrick has on his pinned tweet this article How to be a Great Software Developer that I think is worth a read.

Most people finish college in four years. In retro, the biggest challenge for myself as a developer is that I'm not great at engineering, or say the implementation side of things. My brain calls it a mission complete at understanding the intuitive meaning and I'm still fairly scared at getting my hands dirty.  On the other hand, I think I'm overly well treated by this career and community, and people around me, so I have no excuses. And therefore I'll find ways to get better at implementation and get hands dirty ¯\_(ツ)_/¯.

So yeah, these are my first four years as front end. First thing other than math I've broken my two-year limit in consistent effort. Hopefully I'm a graduate now. By no means saying I'll stop learning or whatever, instead looking forward to the many more four years challenges ahead.

Outerspace Operation

Wei Gao — Sat, 12 Oct 2019 11:17:31 +0000

Background

Recently I'm working on a project generator. I think a blueprint to create a planet is a good analogy. The blueprint is how we want users to build this certain type of planet. And inside this blueprint, there are some core features which we want to share, some for consistency, some others for future exploration. So we extract them out and put them in a "headquarter". The headquarter then exports a few app layer things such that the planets created will look alike. It also provides some APIs to satisfy feature and customizability needs.

Problem

I've been bugged by the thoughts around some "very procedural API". What I mean by very procedural API is something that looks like this:

import { someOuterSpaceOperation } from 'headquarter'

const MyPlanet = () => (
  <div onClick={() => someOuterSpaceOperation('hi headquarter')}>
    called from my planet
  </div>
)

Namely, we don't want the API to look like anything related with the component's life cycle. So no hooks, better no syntax sugars like connect neither. I'm free to hide the logic somewhere, maybe by the boundary of a file import, after which the user of the API may spell the magic code someOuterSpaceOperation().

The but the action is not that outer space. In connects back to certain component inside headquarter, and someOuterSpaceOperation may result in a component update. And in the remainder of the universe, we want creatures on those planets to be able to call someOuterSpaceOperation() without realizing we'll still on the nether of a same React app.

Solution

Honestly, I was very, very stuck with this because I felt my imagination was very limited by the React APIs and the existing libraries. I had some rough thoughts around creating and maintaining some kind of store on our own, maybe write some flexible JavaScript to subscribe to it. But I was unable to see how that should actually happen, or where exactly relevant code should go, until Jinjiang sent me an example demo, which I then developed to this codesandbox.

Rough idea: Create a store and have headquarter subscribe to it. The setter side of the store, however, we export to the planets to consume directly.

So my tiny store will look like this. It maintains a store value, a setter and a getter function, and a way to subscribe to it. It has a couple of assumptions: the store value must be an object, and it allows only one listener. Both assumptions are satisfied in the use case with our headquarter.

class Store extends Object {
  constructor(initValue) {
    super(initValue)
    if (typeof initValue === 'object') {
      this.value = initValue
    } else {
      this.value = {}
    }
    this.listener = null
  }
  get = () => this.value
  merge = newValue => {
    this.value = { ...this.value, ...newValue }
    if (typeof this.listener === 'function') {
      this.listener(this.value)
    }
  }
  subscribe = cb => {
    if (typeof cb === 'function') {
      this.listener = cb
    }
  }
}

export default Store

With this Store class, we can create a store and export the very procedural API we desired, it is free to be called outside of a component's lifecycle,

import Store from './store'
export const outerspaceHQStore = new Store({ agent: 0 })

// setAgent can be called outside of a component's lifecycle
export const setAgent = agent => outerspaceHQStore.merge({ agent })

Now in our headquarter, subscribe to the store and put that store value in a stateful variable, then inside a context.

const AgentProvider = ({ children }) => {
  // manage subscription here
  // put in react component tree an internally maintained stateful variable
  // that is subscribed to the newest val
  const [val, setVal] = React.useState(outerspaceHQStore.get())
  outerspaceHQStore.subscribe(newVal => setVal(newVal))

  return <AgentContext.Provider value={val}>{children}</AgentContext.Provider>
}

Here I used something I learned from Jamie's hook-based Unstated library, wrapping and re-exporting the context provider allows us to keep all the logic about this API in one place.

Then, the users of our very procedural API is able to call setAgent anywhere they want, like this:

const ComponentThatSetsAgent = () => (
  <button
    onClick={() => {
      setAgent(Math.ceil(Math.random() * 1000))
    }}
  >
    call outerspace!
  </button>
)

Then inside headquarter, we're able to grab the variable subscribed to our store from its corresponding context:

const ComponentThatDisplaysAgent = () => {
  // grabs the value from context
  const { agent } = React.useContext(AgentContext)
  return <h1>received call from agent {agent}</h1>
}

Other thoughts

First time I do silly things with React, feels a bit hacky, and very unsure. Turns out, I'm home cooking state management with a connector, with a very naive subscription? Also, the contrast is stiff. I mean, I previously thought it was out of my imagination but it seems pretty obvious to me now.

Relevant links

Annotating Connected Components with Flow

Wei Gao — Mon, 01 Jul 2019 06:11:08 +0000

After Flow 0.85, Flow starts Asking for Required Annotations on implicit calls of higher order components within each file import — export cycle. This facilitates Flow to merge type information from file dependencies before it walks the type structure and conducts type inference.

This helps Flow gain significantly better coverage on higher order components. But it also asks that we explicitly annotate the connected components at file exports. Exporting implicit calls of connect will raise error:

Missing type annotation for OP. OP is a type parameter declared in function type [1] and was implicitly
instantiated at call of connect [2].

In general, to make Flow happy with connect after 0.85 is a two-phase fix. First, you need to explicitly annotate each connected components at file exports. This shall clear all the “implicitly instantiated” errors. Then, if your codebase contains mismatched types between component definitions and usages, Flow will report those errors after you fix the implicit instantiation errors.

Fixing the “implicitly instantiated” errors at calls of `connect`

Note: We need React.AbstractComponent from Flow v0.89+

Annotating at function return

The easiest way to annotate connected components is to annotate at function call return. To do this, we need to know to types of props in our components:

OwnProps: likely contain or equal to what you need as the second parameter to mapStateToProps. If there are props that are not used by mapStateToProps, i.e., the props that "pass through", include them here in OwnProps as well
Props: OwnProps plus the props passed in by mapStateToProps and mapDispatchToProps

Note: Inexact objects don't spread nor $Diff very well. It is strongly recommended that you use exact objects for connected components all the time.

type OwnProps = {|
  passthrough: string,
  forMapStateToProps: string
|};

type Props = {|
  ...OwnProps,
  fromMapStateToProps: string,
  dispatch1: () => void
|};

With OwnProps and Props in figured out, we are now ready to annotate the connected components.

In component definition, annotate the props with Props. The component will have access to all the injected props from connect:

import * as React from "react";

const MyComponent = (props: Props) => (
  <div onClick={props.dispatch1}>
    {props.passthrough}
    {props.fromMapStateToProps}
  </div>
);

When we export, this is also when we normally call connect, annotate the exported component with just OwnProps:

import * as React from "react";

// const MyComponent = ...

export default (connect(
  mapStateToProps,
  mapDispatchToProps
)(MyComponent): React.AbstractComponent<OwnProps>);

Annotating by providing explicit type parameters

We may also annotate connected components by providing explicit type parameters at call of connect with the help of the newest Flow Typed library definition for React Redux. Note that this will also require Flow v0.89+.

The Flow Typed library definition declares connect as follows:

declare export function connect<-P, -OP, -SP, -DP, -S, -D>(
  mapStateToProps?: null | void,
  mapDispatchToProps?: null | void,
  mergeProps?: null | void,
  options?: ?Options<S, OP, {||}, MergeOP<OP, D>>
): Connector<P, OP, MergeOP<OP, D>>;

The libdef also contains a glossary of the abbreviations which decrypts the signature to:

connect<Props, OwnProps, StateProps, DispatchProps, State, Dispatch>(…)

For the most common ways to connect components, we won't need all of the parameters. Normally, we need only OwnProps and Props at the call of connect, and State at the definition of mapStateToProps.

We may use _ (what's this?) as placeholder at unused type parameter positions. A common connect call may look like this:

connect<Props, OwnProps, _, _, _, _>(…)

We include examples for three major use cases of annotating connect with Flow:

Connecting stateless component with mapStateToProps
Connecting components with mapDispatchToProps of action creators
Connecting components with mapStateToProps and mapDispatchToProps of action creators

Connecting stateless component with `mapStateToProps`

type OwnProps = {|
  passthrough: number,
  forMapStateToProps: string,
|};
type Props = {|
  ...OwnProps,
  fromStateToProps: string
|};
const Com = (props: Props) => <div>{props.passthrough} {props.fromStateToProps}</div>

type State = {a: number};
const mapStateToProps = (state: State, props: OwnProps) => {
  return {
    fromStateToProps: 'str' + state.a
  }
};

const Connected = connect<Props, OwnProps, _, _, _, _>(mapStateToProps)(Com);

Connecting components with `mapDispatchToProps` of action creators

type OwnProps = {|
  passthrough: number,
|};
type Props = {|
  ...OwnProps,
  dispatch1: (num: number) => void,
  dispatch2: () => void
|};
class Com extends React.Component<Props> {
  render() {
    return <div>{this.props.passthrough}</div>;
  }
}

const mapDispatchToProps = {
  dispatch1: (num: number) => {},
  dispatch2: () => {}
};
const Connected = connect<Props, OwnProps, _, _, _, _>(null, mapDispatchToProps)(Com);
e.push(Connected);
<Connected passthrough={123} />;

Connecting components with `mapStateToProps` and `mapDispatchToProps` of action creators

type OwnProps = {|
  passthrough: number,
  forMapStateToProps: string
|};
type Props = {|
  ...OwnProps,
  dispatch1: () => void,
  dispatch2: () => void,
  fromMapStateToProps: number
|};
class Com extends React.Component<Props> {
  render() {
    return <div>{this.props.passthrough}</div>;
  }
}
type State = {a: number}
type MapStateToPropsProps = {forMapStateToProps: string}
const mapStateToProps = (state: State, props: MapStateToPropsProps) => {
  return {
    fromMapStateToProps: state.a
  }
}
const mapDispatchToProps = {
  dispatch1: () => {},
  dispatch2: () => {}
};
const Connected = connect<Props, OwnProps, _, _, _, _>(mapStateToProps, mapDispatchToProps)(Com);

Annotating nested higher order components with connect

If you are at the unfortunate position where your component is wrapped with nested higher order component, it is probably more difficult to annotate by providing explicit type parameters, as doing so will probably require that you tediously take away props at each layer. It is agian easier to annotate at function return:

type OwnProps = {|
  passthrough: number,
  forMapStateToProps: string,
|}
type Props = {|
  ...OwnProps,
  injectedA: string,
  injectedB: string,
  fromMapStateToProps: string,
  dispatch1: (number) => void,
  dispatch2: () => void,
|}

const Component = (props: Props) => { // annotate the component with all props including injected props
  /** ... */
}

const mapStateToProps = (state: State, ownProps: OwnProps) => {
  return { fromMapStateToProps: 'str' + ownProps.forMapStateToProps },
}
const mapDispatchToProps = {
  dispatch1: number => {},
  dispatch2: () => {},
}

export default (compose(
  connect(mapStateToProps, mapDispatchToProps),
  withA,
  withB,
)(Component): React.AbstractComponent<OwnProps>)  // export the connected component without injected props

Benefits of this version

After fixing the implicit instantiation errors, if your code contains mismatched types between connected components, the total number of errors may go up. This is the result of Flow's improved coverage. If you are using console output for the Flow errors, you may not be able to see those errors until you clear other errors. These additional errors are grouped together, all tied back to React Redux's library definition, and have friendly error messages that will pin point you to the lines of code to the errors.

References

Articles

Asking for Required Annotations

Upgrading guides

Talks

Flow Be Happy A talk on upgrading Flow past 0.85, slides

Others

Flow Notes A repo where I herd my notes on Flow
Flow Typed tests for React Redux connect
flow-typed/#2946: Discussion after 0.85
Add support for Flow 0.89+: #3012, #3035
What's _?

Notes on Flow 0.100

Wei Gao — Tue, 25 Jun 2019 10:32:15 +0000

Flow 0.100 is out 💯. Reading and learning about Flow and JavaScript as always. This time, I have a short note on object destructuring, React type definitions, and put a link to a nice article explaining variance sigils.

Flow 0.100 has very nice release notes with examples. So I won't repeat what is already said there. Here are some bullet points I jotted down as I tried to learn about the changes.

Destructuring objects in function parameters

Destructuring patterns could previously include missing properties if the resulting binding was unused. This is now an error even when unused. Try Flow example

type O = { p: string }
// Error: There is no property `q` in type `O`, as of Flow v0.100.0
function f({ p, q }: O) {}

One confusion I encountered was this

Does it mean all object will be exact?

So I took this chance to clarify some of the things around here. Exact means the object passed in here must not contain extra fields (link to doc).

Sealed, on the other hand, means the object may contain other fields but you may not access them unless you annotate them. When we write an object type with some fields, it is by default sealed. Trying to access unannotated field of a sealed object will result in error, regardless of it being exact or not:

type Sealed = { foo: string }

const sealed = {
  foo: 'foo',
}
sealed.bar = 'bar' // error
const { foo, bar } = sealed // error

For functions that expect sealed objects, you can still pass in objects with extra props.

function usingSealed(x: Sealed) {
  // does things
}
usingSealed({ foo: 'foo', bar: 'bar' }) // ok

Not so when the functions are expecting exact objects:

type Exact = {| foo: string |}

function usingExact(x: Exact) {
  // does things
}
usingExact({ foo: 'foo', bar: 'bar' }) // error

We may access the fields of function parameters by destructuring the object:

// destructuring on function parameter
function goodUsingSealed({ foo }: Sealed) { // ok
  // does things
}

But since destructuring means accessing the object, we should not be able to access extra props to sealed objects. This is fixed in 0.100:

// fixed in 0.100
function badUsingSealed({ foo, bar }: Sealed) { // error after 0.100
  // does things
}

React component types

There are a bunch of changes around React library definitions. And so it's a good chance to take a step back and look at what they are in all.

Here is the link to the React library definitions by Flow.

My list of commonly used:

React$Component<Props, State = void>
AbstractComponent<-Config, +Instance = mixed>
React$ComponentType<-Config>
React$ElementType
React$Element<+ElementType: React$ElementType>
(new) React$MixedElement = React$Element<React$ElementType>
(new) MixedElement = React$MixedElement
React$Ref<ElementType: React$ElementType>

In the definitions above, those with the angled brackets are polymorphic types. This means you'll need to supply type parameters for those polymorphics.

`React$Component<Props, State = void>`

React$Component is the base class of ES6 React classes, modeled as a polymorphic class whose main type parameters are Props and State.

`React$AbstractComponent`

React$AbstractComponent is the type name used by Flow, and is used by a few different types of React classes and components in React's library declarations.

React.AbstractComponent uses it directly, which takes two parameters, Config for the props type, and Instance for an instance. Functional components have Instance: void.

`React$ComponentType`

declare type React$ComponentType<-Config> = React$AbstractComponent<
  Config,
  mixed
>

Aliased to React$AbstractComponent<Config, mixed>, and is used as the type of a component in React. It can be:

Stateless functional components. Functions that take in props as an argument and return a React node.
ES6 class component. Components with state defined either using the ES6 class syntax, or with the legacy React.createClass() helper.

`React$ElementType`

declare type React$ElementType = string | React$AbstractComponent<empty, mixed>

The type of an element in React. A React element may be a:

string: These elements are intrinsics that depend on the React renderer implementation.
React component. See ComponentType for more information about its different variants.

A few more related with ElementType:

A React$Element is the type of a React element. React elements are commonly created using JSX literals, which desugar to React.createElement calls (see below).

declare type React$Element<+ElementType: React$ElementType> = {|
  +type: ElementType,
  +props: React$ElementProps<ElementType>,
  +key: React$Key | null,
  +ref: any,
|}

Finally, here are the two new types:

declare type React$MixedElement = React$Element<React$ElementType>
declare type MixedElement = React$MixedElement

A keen reader may have noticed that above is more or less a copy and paste of comments and code snippets from Flow's codebase. They are really very well-written and a significant portion of the code itself is self-explanatory.

Variance sigils

Variance sigils are everywhere in library definitions. If this set of synonyms works for you, feel free to think of covariance as read-only, and contravariance as write-only.

This article Flow's Best Kept Secret explains it very well.

🐶 Till next time

Flow 0.101 is already out and I'm falling behind 😭 It's JSConf.Asia at home now. Gonna chill down a bit next week and get back to my normal Flow :]

Flow 0.99: Callable Properties, Function Statics, and More

Wei Gao — Sat, 01 Jun 2019 22:15:18 +0000

Cover image: Text of Time #9

Flow released 0.99 (comparing changes) a few days ago. This release contains changes around callable properties, function statics, a few more utilities coming from the React Component realm, bugfixes, and performance improvements for Flow server.

Once again I'm using those bits and bites to understand more about Flow and JavaScript, and this time it'll be mostly around callable properties and function statics, which I'll share about in this post.

🍾 Function statics

Here is one change that caused new errors in our codebase:

Make function type statics stricter

Before this change, we optimistically typed the statics of a function type as any, under the assumption that a function would not be used as an object. In practice, our optimism here is unfounded.

This diff changes the type of the statics object for function types to an empty, inexact object type with Function.prototype for its proto. This choice is sound with respect to the runtime behaviors while also allowing functions with statics to be valid subtypes via width subtyping.

Time for a review on JavaScript. What are function statics?

For a JavaScript class, a static method is a method for the class, not instances of that class.

For a JavaScript function, statics refer to those weird moments where you may have a variable that can be accessed by saying function name dot that variable name because functions are also objects in JavaScript 🤷🏻‍♀️. Consider this greeting function with a counter:

function greeting(name) {
  if (!greeting.counter) {
    greeting.counter = 0
  }
  greeting.counter++
  return 'hello, ' + name
}

So what this change says is that previously Flow did not put any restrictions on function statics, i.e., they were typed to any. In the example above, this would mean that greeting.counter is a field of any, and is therefore unrestricted.

You may type function statics, for example:

function greeting(name) {
  (greeting.counter: number)
  if (!greeting.counter) {
    greeting.counter = 0;
  }
  greeting.counter++;
  return 'hello, ' + name;
}

Play around in the Try Flow and note that if you change the annotation of counter to string, Flow is catching the error:

4:   (greeting.counter: string)
      ^ Cannot cast `greeting.counter` to string because number [1] is incompatible with string [2].
References:
6:     greeting.counter = 0;
                          ^ [1]
4:   (greeting.counter: string)
                        ^ [2]

🐿 New error in our codebase

The real error that happened in our codebase, however, is a bit different.

We write our Redux actions with data wrapped around in a field conventionally referred to as payload. And we normally annotate payload like this:

type ActionPayload = {
  data: string,
  error: string,
}

Sometimes payload can be a function that returns an object containing the data, so we're happy to see this too:

const fetchData = ({
  type,
  payload,
}: {
  type: 'FETCH_DATA',
  payload: () => ActionPayload,
}) => {
  // function body
}

In a few occasions, though, we mistyped the payload in the function form, where the payload is actually just the object. So our code worked fine and no one noticed that the annotation isn't making sense at all:

const fetchData = ({
  type,
  payload,
}: {
  type: 'FETCH_DATA',
  payload: () => ActionPayload, // <- wrooooong, or not?
}) => {
  return payload.data
}

At 0.99, as function statics are now typed to {}, Flow is complaining that we cannot get data because data is missing in statics of function type.

A similar scenario is a mixture of actions and action creators. They get passed around quite often, which makes typing even hairier. I realize that Flow really is getting in our way when we try to be smart in this direction. I like the flexibility but the complaints will keep asking me whether this is a good pattern or not, which I do not yet have an answer.

👾 Callable property syntax

Remove deprecated $call property syntax

First of all, to not be confused, this is not the $call utility type, which helps you get the return type of a given function, and is not deprecated nor removed.

The deprecated $call property syntax was the precursor of this callable syntax, both the addition of the new syntax and the deprecation of the old happened in 0.75.

So what are they about, anyway?

It ties back to the fact we mentioned earlier that with JavaScript functions are also objects. And here's an interesting insight from Flow:

An object with a callable property can be equivalently viewed as a function with static fields.

And so it turns out:

// You should be able to call objects with call properties
function a(f: { (): string }, g: { (x: number): string }): string {
  return f() + g(123)
}

// ...and get an error if the return type is wrong
function b(f: { (): string }): number {
  return f()
}

And similarly:

// You should be able to use an object as a function
function a(x: { (z: number): string }): (z: number) => string {
  return x
}

Most amazing #TIL for me is perhaps this:

// Multiple call properties should also be supported
function a(f: { (): string, (x: number): string }): string {
  return f() + f(123)
}

// It should be fine when a function satisfies them all
var b: { (): string, (x: number): string } = function(x?: number): string {
  return 'hi'
}

And here is another one that reminds us about functions, that those monadic chained calls made possible by prototypes come down to not much more than a field in a function:

// Expecting properties that do exist should be fine
var b: { apply: Function } = function() {}

So that's a really interesting feature that Flow possesses! That means you can annotate memoized functions with Flow and I never even thought of that before learning all this. Consider a memoized factorial (Try Flow) and you can annotate it expressively with Flow:

type MemoizedFactorialType = {
  cache: {
    [number]: number,
  },
  [[call]](number): number,
}

const factorial: MemoizedFactorialType = n => {
  if (!factorial.cache) {
    factorial.cache = {}
  }
  if (factorial.cache[n] !== undefined) {
    return factorial.cache[n]
  }
  factorial.cache[n] = n === 0 ? 1 : n * factorial(n - 1)
  return factorial.cache[n]
}

There are a few more changes around callable properties in this version, which I'll list out their references:

And here is a couple more links to some older commits you may want to look at regarding callable properties:

🦖 Other notable changes

There are few more notable changes I'll just list here for now:

If you find any of those interesting and have learned something about them, please please write about them because ever since 0.85 my learning about Flow has felt like sitting in a class where no one asks any questions but apparently not many people understand what's going on 🤦🏻‍♀️. Secretly I'm also not completely certain about things I said about Flow. If you spot any mistakes, please do let me know.

💯 Till next time

Flow 0.100 is released too. If you haven't noticed, the release notes now come with Try Flow examples. Maybe the added digit indicates a new era.

Night Mode 🌚🌝 with Mix Blend Mode: Difference

Wei Gao — Sat, 04 May 2019 16:28:15 +0000

I came across the idea of implementing night mode using mix-blend-mode: difference when I was preparing for my talk This World Mixed and Blended (these slides require color font support, i.e., FireFox / Safari). The original idea was only meant for a showcase and the browser support is currently limited.

Still, I implemented it to my dev blog and had a lot of fun. So this will be what this post is about. Meanwhile, as I thought more about it, it occurs to me now that this can be a legit preferred way night mode is to be done. And let me share a bit about the intuition behind that as well.

Please note that this is not a standard way of implementing dark mode. To see how people normally do it, you may want to see here for how Dan Abramov does it for Overreacted, or this post.

Understanding `mix-blend-mode: difference`

mix-blend-mode: difference is one of the blending modes CSS supports, as specified in Compositing and Blending Level 1. Blending modes, in turn, specify how colors mix when graphics are stacked together. The graphics do not limit to images. Any rendered graphics, content of divs, texts, emojis 🌚🌝, svgs, may participate in the blending.

I'd like to think of that as the process where browsers check with us whenever they are about to paint a new element: “Hey, it seems that this next pixel I'm painting is red, but currently I am seeing a blue on the ground, by any chance you want me to combine those colors together, and if so, how?”

Blending modes allow us to create some very interesting effects such as overlaying texts on an image while revealing the texture of the graphics directly in a browser:

Example of blending mode from Compositing and Blending Level 1

Definition

mix-blend-mode: difference, in particular, is one of the blending modes that is defined as taking the absolute value of the difference between the two colors:

difference(A, B) = |A - B|

This is an abstraction of the actual computation, where for each color we meant three numbers representing the R, G, and B channels, respectively. As an example,

difference(
    rgb(255, 255, 255),
    rgb(0, 100, 200)
) = rgb(255, 155, 55)

Meanwhile, taking the absolute value makes the operation commutative, meaning B(A, B) = B(B, A). In another words, it doesn't matter which graphic is laid on top of the other, the result is going to be the same.

Intuition

What exactly is the blending mode difference doing? The definition seems straightforward. However, our minds may not be very good at perceiving what will happen to the resultant color before actually seeing them. To name an example, difference(white, red) is essentially deducing the complement color of red, which is teal. But how can you “see” it until you actually saw it?

The following pen is created by blending intersecting stripes of whites and reds only.

Perhaps exactly because its hardly perceivable effects, we can use mix-blend-mode: difference to create some contrasting visuals to spark surprises in UI, like this one by Sven Wolfermann:

This was the design that inspired me to think about creating dark mode using difference.

Implementing dark mode using `mix-blend-mode: difference`

How does it work?

The idea is simple: When night mode is turned on, cover your site with a full-screen div with background: white and mix-blend-mode: difference, and save yourself the trouble of defining all the colors again 😉

.dark-mode-screen {
  width: 100vw;
  height: 100vh;
  position: fixed;
  top: 0;
  left: 0;
  background: white;
  mix-blend-mode: difference;
}

Why, though?

The thought process involves two of the mathematicians' favorite numbers, 0 and 1.

In unit space, 0 means nothing and 1 means everything.

In RGB colors, 0 means black and 1 (100% or 255) means white.

Now let's think about our blog site, and let's assume that currently we have a white background and a black foreground. If we take the difference of that page against white, what do we get?

background: currently white, the difference between white and white is nothing, which means black
foreground: currently black, which means nothing, the difference between white and nothing is white

Now we have a black background and a white foreground, and look what is that? A reversed (dark) theme :)

Furthermore, when taking the difference of the page with white, the contrast between the original background and foreground is automatically preserved. This does not only apply to blacks and whites. In fact, my code block with original theme Dracula picks up a nice sepia-styled hue when inverted.

Transition

Scaling a div

I put a toggle fixed to the lower bottom of the page. When the night mode is toggled on, I transform that toggle to scale up that covers the whole page. This effect is kind of showing off the original UX design.

Opacity

If you prefer a more subtle toggle, maybe tweaking opacity is a better choice and the blending mode will work just as nice. With an easing timing function on the transition, this is perhaps the transition UI shared by most websites and blogs implementing a night mode.

Isolate the elements that are not intended to blend

As mentioned earlier, mix-blend-mode will apply on any graphics. However, when implementing dark mode, some elements may not be intended to blend. Such examples include logos of specific colors, emojis, etc. To specify that, you can put isolation: isolate (reference) on those elements. Note that this will create a stacking context on the element that is isolated.

/* twitter logo and emoji should not blend */
.twitter-logo,
.emoji {
  isolation: isolate; 
}

/* elements that create their a stacking context are automatically isolated */
.footer {
  z-index: 1;
}

Pick a colored hue for your dark mode

As mentioned earlier, taking the difference between the page against white is like taking the complement color directly. You may not have to limit that choice of color to white. In fact, you can pick any color to take the difference with. For an effect of a darker theme where your site was initially on a light background, you may consider any color that is relatively light:

These are some of the technical details I've encountered. If you're trying this and encounter issues here and there, please feel free to let me know and I'd be glad if I can help.

To see this thing in code, check out this CodePen:

Limits

(apart from being geeky 😅)

You don't have full range of colors. It saves you the trouble of specifying more colors, but you'd lose control over the dark colors — they'd be deduced from your light colors. Yet this may not be a limit but rather a design choice.
Browser support of mix-blend-mode is still not optimal, you're stuck with non-IE, relatively newer versions of browsers.
Performance can be a concern as well for its by-pixel and by-channel computation. Don't do crazy animations with it (yet).

Till next time 🤞

Blending modes were citizens from computer graphics. I remember first playing around with them in Photoshop years ago. Now that browsers are becoming more powerful and we are seeing complex graphical features native to browser rendering. This doesn't mean we should implement a full photoshop in browsers and nor should we limit our imaginations to just that. Browsers and web pages have their own contexts and goals, as well as a different set of limits. Maybe we should welcome them like new habitants and discover use cases native to this territory.

Once again, the inspiration credits to this CodePen, a cute animation that strikes an impression at first sight. You should hover over it 🙈

I hope this serves as a friendly discovery about blending modes, and I hope you had fun same as I do.

Making Flow Happy after 0.98

Wei Gao — Tue, 30 Apr 2019 13:10:58 +0000

It's a Monday after Flow updated 😱 0.98 seems to contain many fixes. Happy to see Flow making more sense version by version. I'm also glad to be learning bits and bites about Flow on the go so I thought I'd share about that :)

Release notes are here, and following are my notes. Flow please be happy 🤞

Turn the deprecated-utility lint on by default

Possible errors:

Deprecated utility. Using $Subtype types is not recommended! (deprecated-utility)
Deprecated utility. Using $Supertype types is not recommended! (deprecated-utility)

deprecated-utility is a lint rule that was added in 0.89. So far $Subtype and $Supertype are deprecated. However, Flow only starts to complain from this version because deprecated-utility is now turned on by default.

You can turn it off by adding back the lint option in .flowconfig:

# .flowconfig
[lints]
deprecated-utility=off

But it's actually not that hard to fix.

So what were $Subtype and $Supertype anyway? $Subtype normally means what is expected here is more refined than what's inside $Subtype. Anyway, that's just my understanding. You can still find the docs here.

Perhaps you previously used $Subtype to refine component props, as suggested at the time of their deprecation, you can bring back the refinement using bounded generics.

Some older version of library definitions from Flow-Typed may raise errors. (For example, we were using Redux v3 before Flow 0.89 that caused unhappiness. However, there is already a libdef update in Flow-Typed.)

I felt a bit hairy about them anyway. Now that they're gone, time to feel happy and get rid of them :)

Changes and fixes around read-only object and array

Possible errors:

Cannot assign 42 to x[0] because read-only arrays cannot be written to.
Cannot assign array to problem because read-only array type [1] is incompatible with array type [2].
Cannot assign 3 to x.a because property a is not writable.

It's great to see that Flow is constantly improving and how. (Plus with a slight hint of humor to read about the fixes on the previous unsoundedness).

So I've found three changes and fixes around read-only things.

Read-only arrays cannot be written to with any-typed indexes, commit

This now disallows you to mutate read only arrays. And you may ask, why should I be allowed to mutate them anyway? Turns out previously if the index is of type any you would have been able to. 🤷🏻‍♀️

Then there are two more:

Mixed refines to read-only object under typeof = object, commit
Mixed refined by array produces $ReadOnlyArray, commit

I do not have a better explanation than the commit messages there. So let me quote:

[Bugbash] Mixed refines to read-only object under typeof = object
Summary:
It is not safe to refine mixed to {[string] : mixed} because this allows writes of any kind into the refined object, and we don't know what type of values the object holds. The only safe operation is to read mixed out of the object, so the properties must be read only.

function bad (x : mixed) {
  if (typeof x === "object" && x !== null) {
    x.a = 3;
  }
}

let obj : {a : string} = {a : "oops"};
bad(obj); // yikes

And the one with arrays:

[Bugbash] mixed refined by array produces $ReadOnlyArray<mixed>

Summary:
It is not safe to refine mixed to Array<mixed> as this allows for writing arbitrary values to the result of the refinement, and since we only know that the value is an array, we cannot know that it is safe to write a given value to the array. We do know, however, that anything we get out of the array will be mixed, so it is safe to type it as a $ReadOnlyArray<mixed>.

function bad(array: mixed) { 
  if (Array.isArray(array)) { 
    const problem: Array<mixed> = array; problem[1] = 0; 
  }
}
bad((["3"] : Array<string>));

Infer void before type checking starts for functions without a return statement

Possible errors:

Note: I think the possible errors caused by this fix can be quite variable. Here are two I know of:

Cannot cast x.noReturn() to number because undefined [1] is incompatible with number [2].
Cannot shadow proto property yourFunction [1] because object type [2] is incompatible with undefined [3] in the return value.

Commit on Flow codebase: Infer void early for functions with no explicit return

If a function does not have a return statement, Flow now infers that to void. Interestingly, the most common errors that arise after this were regarding shadowing proto property. Check out the following Try Flow:

import * as React from 'react';

class MyComponent extends React.Component<*> {
  handleClick: () => {};  // <- {} means an object here

  handleClick() {
    console.log('clicked!');
  }

  render() {
    return <div onClick={this.handleClick} />
  }
}

Fixes are simply to annotate them properly () => void

Fix a bug which prevented Flow from asking for required type annotations.

This line sounds scary 😱 But I haven't encountered any unhappiness that seems related yet. Will come back here if I do.

Forem: Wei Gao

Animated CSS Blob

CSS border radius

Animation

Blending

Rethinking React Knowledgeable

Rethinking RK

Do we want to keep scaling up like a conference, or do we want a smaller learning group?

Should it be topic-based or people-based?

What's the learning process that RK should highlight?

How it works

What RK asks of you

What this really is

FAQs

Play with React Concurrent Mode with Your Gatsby Site [updated with more proper solution]

TL;DR

Notes

More notes

When and how does Gatsby call render?

What does ReactDOM.hydrate do in a Gatsby site?

What happens if the DOM isn't properly hydrated or onInitialClientRender isn't properly called?

Links

Re-export Context Provider

Problem

Approach

Relevant links

Properly Include Component Function from `useEffect` and `useCallback` Dependency List

Relevant links

4 Years as Front End

Year 1

Year 2

Year 3

Year 4

Outerspace Operation

Background

Problem

Solution

Other thoughts

Relevant links

Annotating Connected Components with Flow

Fixing the “implicitly instantiated” errors at calls of connect

Annotating at function return

Annotating by providing explicit type parameters

Connecting stateless component with mapStateToProps

Connecting components with mapDispatchToProps of action creators

Connecting components with mapStateToProps and mapDispatchToProps of action creators

Annotating nested higher order components with connect

Benefits of this version

References

Notes on Flow 0.100

Destructuring objects in function parameters

React component types

React$Component<Props, State = void>

React$AbstractComponent

React$ComponentType

React$ElementType

Variance sigils

🐶 Till next time

Flow 0.99: Callable Properties, Function Statics, and More

🍾 Function statics

🐿 New error in our codebase

👾 Callable property syntax

🦖 Other notable changes

💯 Till next time

Night Mode 🌚🌝 with Mix Blend Mode: Difference

Understanding mix-blend-mode: difference

Definition

Intuition

Implementing dark mode using mix-blend-mode: difference

How does it work?

Transition

Isolate the elements that are not intended to blend

Pick a colored hue for your dark mode

Limits

Till next time 🤞

Making Flow Happy after 0.98

References

When and how does Gatsby call `render`?

What does `ReactDOM.hydrate` do in a Gatsby site?

What happens if the DOM isn't properly hydrated or `onInitialClientRender` isn't properly called?

Fixing the “implicitly instantiated” errors at calls of `connect`

Connecting stateless component with `mapStateToProps`

Connecting components with `mapDispatchToProps` of action creators

Connecting components with `mapStateToProps` and `mapDispatchToProps` of action creators

`React$Component<Props, State = void>`

`React$AbstractComponent`

`React$ComponentType`

`React$ElementType`

Understanding `mix-blend-mode: difference`

Implementing dark mode using `mix-blend-mode: difference`