DEV Community: Alex Reardon

Wait for pending: A Suspense algorithm exploration

Alex Reardon — Tue, 25 Jun 2024 05:05:35 +0000

There is some great discourse going on about how <Suspense> timing should work in react@19.

In this post I explore what a <Suspense> algorithm would look like if all pending promises in a <Suspense> boundary were resolved before trying to re-render.

This started as a scratch pad, then a proposal, then I saw some problems with the approach... but I thought I would record and share it all the same. Maybe it might lead to some other better ideas!

TLDR

'Wait for pending' is an interesting variation of the react@18 and react@19 (alpha) <Suspense> algorithms. For flat async trees, 'wait for pending' allows for fast calling of render functions, and minimal re-renders. For trees with nested async components, child async components will have their initial render called slower than the react@18 algorithm.

Background

<Suspense> in react@18

render all possible components inside a <Suspense> boundary.
Re-render when any promise resolves
Continue until no more components throw a promise

Results in lots of rerenders, but allows parallelization of 'fetch in render' calls, and all components will have their render called as quickly as possible.

<Suspense> in react@19 (alpha)

stop rendering tree when a component throws a promise
wait for promise to resolve
re-render tree
Continue until no more components throw a promise

Results in minimal rerenders - but causes 'fetch in render' calls to be sequential (waterfall)

'Wait for pending' algorithm

Here is an idea for <Suspense> timing ('wait for pending'):

Always render siblings, even when they throw (like Suspense in react@18)
Don't re-render children until all currently thrown promises are resolved.

Let's see how it goes!

'Wait for pending' is similar to the current react@18 <Suspense> algorithm, except that rather than rendering all children when any thrown promise resolves, only render when all currently thrown promises resolve.

Allows for 'fetch in render' in siblings to trigger parallel fetches
Still has a great story for pre-fetching
Reduces the waste caused by re-rendering possibly expensive components
Expensive component renders along side siblings that throw will still be redundant. But, at least these redundant renders are reduced
👎 Can slow down nested 'fetch in render' calls (see below)

Rough algorithm

render children
if no thrown promises, done - otherwise go to step 3
wait for all thrown promises to resolve
go to step 1.

Example 1: Only siblings

<Suspense fallback={'loading'}>
  <A />
  <B />
<Suspense>

In this example, both A and B have a fetch for data in their render

`react@18`

Render 1

A renders, but throws a promise
B renders, but throws a promise

Render 2

promise from A resolves
A renders
B renders, but throws a promise

Render 3

promise from B resolves
A renders
B renders

`react@19` alpha timing

Render 1

A renders, but throws a promise

Render 2

promise from A resolves
render A
render B, but B throws a promise

Render 3

promise from B resolves
render A
render B

😢 causes waterfalls if you fetch (throw) in renders
😊 avoids excessive re-rendering potentially expensive components

Wait for pending

Render 1

A renders, but throws a promise
B renders, but throws a promise
wait for A and B to resolve

Render 2

A renders
B renders

✅ In this case, the proposed algorithm yields great results!

Example 2: With children

Here is where 'wait for pending' strains.

Now A renders children ChildX and ChildY which also do a 'fetch in render'

<Suspense fallback={'loading'}>
  <A>
    <ChildX />
    <ChildY />
  </A>
  <B />
<Suspense>

`react@18` algorithm

Render 1

A renders, but throws a promise
B renders, but throws a promise

Render 2

promise thrown by A resolves
A renders
ChildX renders, but throws a promise
ChildY renders, but throws a promise
B renders, but throws a promise

Render 3

promise thrown by ChildX resolves
A renders
ChildX renders
ChildY renders, but throws a promise
B renders, but throws a promise

Render 4

promise thrown from ChildY resolves
A renders
ChildX renders
ChildY renders
B renders, but throws a promise

Render 5

promise thrown from B resolves
A renders
ChildX renders
ChildY renders
B renders

✅ ChildX and ChildY get rendered as early as possible
😢 Lots of redundant re-rendering

`react@19` alpha algorithm

Render 1

A renders, but throws a promise

Render 2

promise from A resolves
render A
render ChildX, but B throws a promise

Render 3

promise from ChildX resolves
render A
render ChildX
render ChildY, but ChildY throws a promise

Render 4

promise from ChildY resolves
render A
render ChildX
render ChildY
render B, but B throws a promise

Render 5

promise from B resolves
render A
render ChildX
render ChildY
render B

Proposed algorithm

Render 1

A renders, but throws a promise
B renders, but throws a promise
wait for A and B to resolve

Render 2

promise thrown by A and B resolve
A renders
ChildX renders, but throws a promise
ChildY renders, but throws a promise
B renders
wait for ChildX and ChildY to resolve

Render 3

promise thrown by ChildX and ChildY resolve
A renders
ChildX renders
ChildY renders
B renders

✅ A lot less redundant rendering than the react@18 algorithm
👎 ChildX and ChildY need to wait for B to resolve before kicking off their 'fetch in render' calls. They had to wait for the slowest sibling of their parent to resolve before they could kick off their promises.
🤔 More parellisation than the react@19 algorithm, but slower to kick off initial renders for all components than react@18.

Closing thoughts

'Wait for pending' is an interesting approach.

For flat async trees, 'wait for pending' allows for fast calling of render functions, and minimal re-renders. However, when there trees with nested async components, async child components have to wait for their parents siblings to finish rendering before their initial render function is called. If the nested component was doing an expensive operation (such as a network call), then triggering the initial renders as quickly as possible is ideal (the react@18 algorithm). The 'wait for pending' is similar to the react@19 approach - except that each level can be parellised.

It was interesting to think about what a different <Suspense> algorithm could look like! Thanks for making it this far 😅.

Cheers

The Commute Rule

Alex Reardon — Sun, 21 Aug 2022 23:15:06 +0000

The Commute Rule: If you are too sick to commute to the office, don’t work from home

This year I have fallen into a bad habit: being moderately sick, but pushing through the sickness and working from home. Since the beginning of COVID I have been working from home. Something I have become aware of is that the barrier to get to work when working from home is extremely low. All I need to do is slink over to my desk, sit upright and clink away on my keyboard. I usually can do that even when I am moderately unwell.

In the past I have written about why I think it is important that we rest when we are sick: Take a real sick day and I still stand by that.

Taking time to recover well seems to lead to shorter illnesses

Working while moderately sick is pretty miserable for everybody and fosters a culture where people feel pressured to work while unwell

Taking a real sick day challenges us to find our self worth outside of our outputs

Sometimes we can be "sick" and it is mild, and has no real impact on our days (eg a small cough). What I needed was some good general rule that I could use for myself that would help me decide whether I was too sick to work from home. A rule I came up with was the commute rule: If I don’t think I am well enough to have a shower, get changed, walk to the train station, catch a train for 45m to the city and walk to the office; then I should not work from home. If I was working in the office, I would not be going to work if I was unable to do the commute. I can apply the same test for working from home.

This rule isn't perfect:

People have different commutes
You might be not wanting to commute due to infectiousness, and not ability
Probably a few other reasons

Even though this rule isn’t perfect, I have personally found it useful I thought I would share it.

I hope you are doing well,

Cheers

How to grow as a software engineer

Alex Reardon — Mon, 28 Mar 2022 22:04:00 +0000

In this blog I share some advice on how to grow as a software engineer that I have collected through my own experiences, reading and observations.

In the space of about 17 years I have personally grown from not knowing programming at all to being a Principal Engineer at Atlassian. I have built some cool things I am proud of and I have worked with some amazing people. I have been involved in mentoring, interviewing and promotions, and I have some practice in thinking about how to guide, level and grow engineers.

This blog is targeted at people who are entering into the software industry. The content of this blog was originally given as a presentation to University students. I cover a fair amount of ground in a relatively short period of time. I hope that my words can carry you into deeper thought and exploration.

Giving general advice is a difficult exercise as few things are universally true. I acknowledge my advice is likely shaped by my privilege as a white native english speaking male (hard to escape my own bias).

Summary

In order to grow as a software engineer, there are three parallel and overlapping areas that you will want to improve in:

👩‍💻 Technical proficiency
👀 Contextual awareness
✍️ Communication skills

In addition to talking about these areas, I will also give some general pointers:

You are worth more than your outputs
Be kind to yourself
Adopt a learners mindset
Dangerous accelerant: side projects

Let's do this.

Area 1: 👩‍💻 Technical proficiency

How well do you know the programming language(s) and technologies that you are working with?

Master the fundamentals

The foundation of your value as a software engineer is technical proficiency. You want to pursue an ever increasing understanding and familiarity with the programming language(s) and technologies that you work with day to day. A strong technical proficiency will allow you to craft robust, clean, valuable and creative solutions.

You will want to get a good grip on:

Foundational language building blocks, such as: variables, loops, functions, conditions, type systems, type coercion, classes, objects, collections, input and output and so on.
Language grammar and semantics (don't shy away from the hard parts - even if you don't use them right away, you might encounter them or find use for them at some point)
Scoping rules (what things can be accessed when, and by what)
Error handling
Code reuse and sharing patterns
Asynchronous behaviour

There are so many ways you can grow in technical proficiency, and I don't think there is any one right way. Find some option(s) that you find interesting and motivating.

Here are some ideas for how you can grow your technical proficiency:

Read technical books
Read industry newsletters
Watch courses
Attend meetups
Attend conferences
Read blogs
Listen to podcasts
Create your own side project (more on side projects later!)
Get involved in open source (make your own project, contribute to another, read the source another)
Experiment, fiddle! Find a way for you to run cheap little experiments to validate behaviour and try things out
Seek understanding of why something does not work (or does work)
Find (safe) people and learning communities you can ask questions to (eg twitter, reddit)
Share your learning with others (blogs, meetups, book clubs)

My memory is pretty terrible, and knowledge that I don't use regularly tends to fade. I think that is a pretty common experience. So what I do is learn where I can find good information on particular topics, even if I cannot remember all the specifics about the topic.

"Get the fundamentals down and the level of everything you do will rise" - Michael Jordan

Ask questions about your code

Over time, you should get comfortable asking deeper questions of your code. Knowing how to gather good answers to the following questions will increase your impact and effectiveness:

How confident am I that my code is behaving how I expect? (types, testing, language familiarity)
How do I go about troubleshooting problems in my code? (debugging)

Tip from @AndaristRake: logging is great for debugging (eg with console.log()), but learning to leverage a proper debugger can power you up quite a bit

How do I know if my code is working in production? (monitoring)
How many people are using my code and how are they using it? (analytics)
How can I use a server to do actions for me: tests, linting, releasing and so on? (continious integration)
What are the performance characteristics of my code? (profiling, benchmarking)
How do people learn how to use my code successfully? (documentation)
How can people of differing abilities interact with the software I make? (accessibility)
How can I (safely?) evolve my system over time? (migrations, evolutions)

Not all questions will apply to every language / stack, but you will get the broad idea

Understanding and balancing tradeoffs

There is rarely a perfect solution to any problem in computer science. As software engineers, we are always balancing tradeoffs. Over time you will want to become familiar with identifying and balancing the benefits and drawbacks of solutions.

You will grow in your understanding relevant tradeoffs by:

Compare answers to [↑ See: Ask questions about your code]
[↓ See: Bare the consequences of your choices]

Weighing tradeoffs often involves considering many non-technical considerations as well [See: ↓ Area 2: Contextual awareness].

Explore popular industry solutions

For your programming language, are there popular libraries or frameworks for solving common problems? Give them a go! See how they feel to you. Try to gain an understanding of the solutions benefits and drawbacks.

Bare the consequences of your choices

When we create code, it will generally go through a number of high level phases:

Creation
Iteration and long term ownership
Deletion

Ideally, you want to try to get experience with the entire lifecycle. You won't know how particular choices pan out straight away. Often it takes extended periods of time, multiple consumers, changing requirements and so on, to expose the true benefits and drawbacks of various technical choices. You can then feed these learnings into future decisions.

Version control

In order to successfully collaborate with other engineers, you will need to have a working knowledge of a version control tool: git. At this point I wouldn't recommend you learn alternative version control systems unless you need to. A working knowledge of git is a good mental model as well as familiarity with the basic commands. git is also a gateway getting a server to automatically perform actions on your code (test, lint, deploy and so on).

Thankfully, there are lots of fantastic git learning materials which a light Google search will reveal.

Area 2: 👀 Contextual awareness

Your (beautiful) code does not exist in a vacuum. You will be more effective the more you can appreciate the multiple wider contexts that your efforts fall into.

Technical context

Gain a good general 'full stack' understanding

For many engineers, you will be working on applications that span multiple layers of technologies. If you work in one of those environments, it is fantastic to gain a working understanding of all of the layers in that stack. Understanding more about the requirements, features, constraints, strengths and weaknesses of various layers in the stack you work in will help you to create solutions (or pieces of solutions) that plays into the strengths of various layers.

I am not advocating that you need to become a 'full stack engineer', rather, that you have 'full stack appreciation'.

Team context

Growing as an engineer also means helping the other people around you be successful too. Being a lone star on a project is not a healthy long term model for any project. Helping other people be successful has a multiplication effect for your project. What are the tools, processes and systems that can help your teammates be successful?

"We rise by lifting others" ― Robert Ingersoll

Business context

Having an understanding of the business (or project) you work for, and it's goals will help you align your efforts and advocacy. I have seen many initiatives and creative solutions be adopted because the driver of the solution understood the business goals and needs. You can burn time trying to redirect a business (or project) in a direction that you think is great, but doesn't line up well with it's goals. There is a time and a place for encouraging redirections - but it is helpful to know when you are pushing with or against the currently planned destination.

Industry context

While software engineering and problem domain foundations don't really change all that often, there is a constant evolution of ideas and offerings.

There can be benefits in observing larger industry trends:

Exposure to new techniques, projects and tools
Sanity check your ideas against existing solutions
Identity market opportunities

How can you keen up to date with industry trends? Similar methods to how you can grow in your technical proficiency:

Read industry newsletters
Watch courses
Attend meetups
Attend conferences
Read blogs
Listen to podcasts
Join learning communities

Area 3: ✍️ Communication skills

The reality of creating software is that you will be communicating (a lot) with other people. Regardless of whether you are a solo open source developer or an employee at a mega software corp - communicating well with others is critical to your effectiveness.

I can almost feel some people cringe as they read this. You might be thinking:

"I just want to write code! I didn't go into software to become a people person!"

I can empathise with this. I am not advocating you need to become a highly articulate and eloquent socialite - rather, that you grow into being able to share clear and helpful information with other people. That doesn't sound too bad - does it?

Good communication leads to increased alignment and clarity, so that you, and the people you interact with, can focus on constructive things. Poor communication leads to a lot of friction, frustration and wasted effort for you, your teammates, your organisation and your users.

Code authoring

The code we write is just as much for communicating with your future self, and for other people, as it is for the machine to execute. Being able to have clear ways of communicating your intention and rationales in your code is essential for code that needs live more than a few weeks. Writing code that is easy to follow is a strong signal of engineering seniority as it demonstrates the understanding that code will need to be well understood by someone that lacks context at a later date.

Some general tips:

Optimise for readability (this covers a lot of things)
Avoid 'magic one liners'.
If you really need hard to read code, hide it behind a nice API
Use comments when you think something requires additional information that is not apparent looking at the code itself
Types (and their names) can be a great way to communicate extra information
Prefer explicit behaviour rather than implicit
Only enforce style preferences that are backed by automatic tooling

Code reviews

Reviewing code (often through a 'pull request') is a common industry practice to help ensure software quality. There is so much to say about pull requests - you will find heaps of tips after a light Google search.

Pull requests are communication intensive. When you are creating a pull request, or reviewing it, you want to aim to be as clear as you can and who needs to do what. Pursing clarity in pull requests will lead to higher quality changes and for potential changes to be accepted / rejected faster.

Persuasion

Other people will need to make decisions based on information that you provide them. Here are some questions people might approach you, or your outputs with:

Which solution should we adopt?
Why should we invest in your idea?
Why should I buy your product?
Why should I adopt your open source project?
Why should I hire you?

Using established persuasive communication techniques can help make connections between a need and a solution clear and straightfoward.

Persuasive communication is a skill that can be learned and improved. I personally was exposed to formal persuasive communication through a law degree (that I otherwise do not use much now). But a small Google search will reveal a number of blogs and courses on how you can learn and improve at persuasive communication.

For me, persuasive communication is not about tricking people, but about making your proposed value propositions clear and easy to follow. Doing this well will help others buy in or opt out more quickly, and for the right reasons.

General pointers

I have shared three general areas for you to focus on improving in order to grow as an software engineer. Here is a collection of other thoughts that you might also find helpful.

Pointer 1: You are worth more than your outputs

My limited and subjective experience is that if you choose to define your self worth based on your outputs you will never be truly satisfied. Your self worth will rise and fall in proximity to your most recent success. I strongly believe the all human beings have dignity and worth is not tied to their outputs. Try to find a way to derive your sence of self worth from something other than your outputs. I am deeply and painfully aware this is no easy task, but I have found increasing joy in trying to decouple my self worth from my outputs.

Pointer 2: Be kind to yourself

You could spend all your time and effort becoming a great software engineer, and you would probably become one. Being good at your craft is awesome, but I think there is also so much more of the human experience for you to enjoy. If you work in software engineering, you will likely have many decades of working ahead of you. It's okay to take your time and enjoy the journey.

Pointer 3: Adopt a learners mindset

A great way to encourage your long term growth is to adopt a position where knowledge is not secret, but learnable (and forgettable!)

Some tips:

Ask lots of questions
Be okay with saying "I don't know" (espeically as you get more senior - it is license for more junior folks)
Find ways that let you answer questions on your own quickly
Be open to changing your mind on things. Try not to emotionally invest in technical positions because it can make it harder to change your mind when you should
Challenge existing ideas
It is okay to forget things (even basic things). It is very human. Be open about calling out that you don't remember something.

Pointer 4: Dangerous accelerant: side projects

I have a love hate relationship with side projects.

Side projects could be things like:

Creating an open source library
Contributing to an open source library
Making your own product
Making your own game
Creating digital art
Soo many more things (I don't want to limit you!)

Side projects often put you in the drivers seat of a project and let you leverage your personal time to have more agency to execute on creative / risky things often with little consequences. Side projects are a powerful vehicle of personal growth on many vectors. However, they are a dangerous accelerant. It is easy to soak up significant amounts of your time with side projects. Speaking from painful personal experience - side projects can cost you more than were expecting to pay. Should you do a side project if you have the opportunity and inclination? For sure! But be careful.

More reflections of mine on side projects

Thanks

I hope you find the advice I have shared helpful. Thanks to the people who helped review and give feedback on this blog.

You can follow me on twitter at @alexandereardon

Cheers

Gardening

Alex Reardon — Tue, 21 Jan 2020 21:55:17 +0000

I was standing in my backyard and I could see lots that needed to be done: hedge trimming, grass mowing, dead branches to be removed, and so much more. I started on consolidating some unused flower pots into a single spot. While doing that I thought it would be a good idea to remove an overgrown fern. I pulled the fern down and then got distracted by the idea of some other task.

My Dad, who is a gardening enthusiast, arrived about an hour later to drop off some tools. He took a look around at my yard and gave me some advice. He encouraged me to finish one job completely and to tidy up any mess before moving onto the next job. Without realising I had started three or four different jobs - all currently at different levels of completion. My Dad's logic was that you might be interrupted at any point and you don't want to be in a position where you are left with large cleanup jobs, or where you have to leave the yard in a bad state with unfinished and dangerous things around.

I spent the next few hours going through each of the jobs I had started earlier and finished them one by one, cleaning up as I went. I didn't get through as much of the gardening as I would have liked that day (things had a bad habit of taking longer than I expected) but everything I started I finished. I could come back another day to do the remaining jobs. The yard was left tidy and the kids could enjoy it.

Focus on one task at a time. Get it done. Tidy up. Then move on

Overhauling our collision engine

Alex Reardon — Thu, 05 Dec 2019 03:24:06 +0000

How we created a more delightful drag and drop experience

Drag and drop is a very human interaction: pick something up and move it somewhere else. react-beautiful-dnd (rbd) is an open source library we created at Atlassian that attempts to reflect the physicality of this human interaction in order to provide a more relatable experience.

rbd contains logic for calculating what should move out of way of the dragging item, and what droppable area the dragging item is currently over (the collision engine). Over time, some limitations of the collision engine have emerged. This blog will share our journey rebuilding the collision engine in order to make drag and drop more delightful.

Problem 1: Knowing when to move

The original collision engine used the centre position of the dragging item to determine what other items should move out of the way. An item would move out of the way when the centre position of the dragging item goes over the start or end edge of another item.

"a dragging items impact is based on its centre of gravity — regardless of where a user grabs an item from" - Rethinking drag and drop

✅ When items are roughly the same size then the interaction is all good

✅ Using the centre position of the dragging item holds up when dragging large items next to small items

❌ Using the centre position of the dragging item does not work well when dragging small items next to large items

In this example, when moving a small item past a big item, the big item would satisfy the condition to move up (the dragging centre is after the top edge), and once moved up, it would satisfy the condition to move down (the dragging centre is before the bottom edge). This would cause big item not being dragged to flicker up and down.

We overcame this weakness in the old collision engine by checking different edges depending on what direction the user was heading in. For example, when moving down in a list we only check to see if the centre of the dragging item has gone past the top edge of another item.

This solution (hack) was not without drawbacks. When dragging large items next to small items, things quickly turn into a dumpster fire if the user changed directions quickly.

When dragging large items next to small ones, small direction changes could result in quite a different displacement of items.

So yeah, things were not great.

Solution: Flipping the logic

The shortcomings of the collision engine have lingered on in the rbd repo for quite some time. There was an open question as to how to maintain physicality, while also overcoming problems with using the centre position of the dragging item.

About a month ago we got a fantastic suggestion from @caspersmith: flip the logic. Rather than using the centre position of the dragging item for determining displacement, look at the centre position of the other items. When an edge of the dragging item goes over the centre position of another item, then move that item out of the way. It turned out that this idea holds up extremely well mathematically and still feels great.

By using the edges of the dragging item we can never end up in a situation where we hit the same item before and after it is displaced, regardless of the items size. The new approach also means we no longer need to lean on the user direction (hack).

Problem 2: What is being dragged over?

When dragging something around we need to communicate to the user what droppable area the dragging item is currently over. Previously we did this by exclusively using the centre position of the dragging item. This is done in an attempt to make the dragging item feel more physical: by using the centre position we are using the dragging item's centre of mass to control its location.

✅ Things feel fantastic when lists are roughly the same size

❌ Significant problems arise when a user is trying to drag a large item into a small list

It can be jarring (and sometimes impossible) for users to drag a big item into a small list. They need to line up the centre position of the big item over this list - which can require overshooting the list with your cursor to get the centre position in the right spot.

Solution: Understanding intention

We spent many hours whiteboarding various potential strategies to improve the experience for dragging large items into small areas. I think we lost a few years of our lives during this process.

The new approach

Find drop candidates 🙋‍♀️(droppable areas that could be the active area)
Choose the drop candidate furthest away from where the drag start started

Finding drop candidates 🙋‍♀️

Previously there was only one way to determine what the droppable area would be: the dragging item centre position. We have now added more ways for droppable areas to be the active droppable area.

A droppable area can be a drop candidate when

Centre hit (existing): the centre position of the dragging item is over the droppable area
Cross axis hit (new):

(this logic only comes into play when dragging large items into smaller sized areas)
- There is some overlap of the dragging item and the droppable area; and
- Only one edge of the dragging item is over the list on the cross axis of the droppable area; and
- The edge must have gone past the cross axis centre of the droppable area (end edge > cross axis centre line, start edge < cross axis centre line)
Totally covered on cross axis (new):
- The dragging item is totally over a droppable area on the cross axis
- There is some overlap on the main axis

Choose candidate that is furthest away

When there are multiple drop candidates (multiple drop areas that we think the user is over) we choose the one that is furthest away from where the drag started. There will only be multiple drop candidates when dragging large items over small droppable areas, so this logic doesn't come into play for the standard use case of dragging items over areas that are of a similar size on the cross axis.

Determining what drop candidate is furthest away is not as straightforward as measuring the distance between the centre points of the droppable areas (which is what we started with). Doing that gives preference to giant droppable areas as their centres are often far away. Rather, we measure the distance between where the dragging item started, the point at which the dragging item hits the cross axis of the droppable area.

What does the new approach achieve?

When droppable areas are roughly the same size on the cross axis, things will operate in the same way they did before: the centre position will be used to control what droppable area an item is over (which feels great)

Strictly using the dragging items centre position was our ideal situation for all interactions. But, as we have seen, using the centre doesn't work well for moving big items into small lists. We looked for a solution would best respect the users intention. We landed on the view that when a draggable item hits a new droppable area it is likely that the user is trying to move into that area - so that is what we will try to give preference to. That is why we give preference to areas that are further away from where the user started. Doing this also requires the least amount of movement to move something into a new area.

We decided this new strategy for large items was a necessary divergence from the physicality of rbd in order to provide an experience that feels intuitive and delightful for users, which in the end, is what we are pursuing physicality to achieve.

Thanks

We hope you have enjoyed this blog, and that you and the people who use your software enjoy the overhauled rbd collision engine. The new collision is available in the 12.2.0 release of rbd.

Thanks to all the Atlassian's who helped work on this and to Daniel Del Core, Michael Dougall and Ee Venn Soh who helped put this blog together.

Cheers

What does react-beautiful-dnd cost to maintain?

Alex Reardon — Tue, 21 May 2019 01:08:13 +0000

The aim of this blog is to make visible the ongoing effort required to maintain the open source drag and drop project react-beautiful-dnd (rbd). The maintenance of the rbd project will look different to other open source projects, but I thought it would be insightful nonetheless. By exposing maintenance information I hope to dispell the myth that open source projects lead to less total effort then private source. There are huge advantages in open source, but the cost of ownership is not one of them.

`rbd` is popular and much loved ❤️

I have been lucky enough to work close to full time on the rbd project for almost two years at Atlassian and I am it's primary maintainer. rbd is used widely internally (Jira Software, Jira Portfolio, Jira Service desk, Trello and Confluence to name a few) and externally (Facebook, box, Zendesk and much more). It is now in the top 20 starred React projects and it one of the most downloaded drag and drop packages on the web. The package has been an ongoing source of praise for Atlassian.

The best defence is a good offence 🏈

Optimising for self-service

I have adopted strategies that aim to maximise peoples ability to get started with rbd, use rbd, and troubleshoot issues without needing to reach out directly (self-service). They include:

Created a free egghead.io quick start course to talk people through getting started with the library step by step.
Created and maintain extensive documentation
Adding development only console warnings for detectable setup issues. That way people do not need to consult the docs for most setup issues
Creating a common setup issue guide
Creating issue templates to help people to debug their own issues before reaching out
Using repeated issues as a signal for unclear documentation or a good development only warning

No open bugs 🐛❌

I have taken a fairly bold stance with rbd: I will not ship any new features while there are open bugs. This might seem unobtainable, but rbd has now been using this strategy successfully for almost two years. By keeping the quality bar high I have reduced the need for people to reach out. This lowers the amount of time I need to spend on maintenance.

Rant 🌶

It is hard to know if a bug is trivial or if it exposes a foundational issue. In order to confidently move forward with a software project we need to know that what we are building on is solid - otherwise, we can drown in fixes and rework. When people use a project they want it to work. It is okay for a project to have limitations - but to not deliver on what it claims to do is trust-destroying.

Workload 👷‍♂️

I have mentioned that I do a lot to promote self-service of rbd. However, people still do reach out for a variety of reasons. These collectively add up to a rough average of one day a week of work. The amount of effort fluctuates week to week.

Bug reports 🐛

I get about one bug report every 1-2 days. There are a few types:

Ghost issue: an issue is created without much detail or an example. I ask for more information and a demo (I provide a boilerplate demo). I then hear nothing back, ever. I need to then come in some time later and close the issue. I let them know they can reopen the issue if they provide more information.
Simple setup issue: some issues raised can be resolved by simply telling people to look at their console (as it can already be telling them what their issue is and how to fix it), or pointing them to our documentation. A large amount of these come from people who are getting started with React and rbd is in one of their first projects. So often people are fighting with React issues rather than rbd issues
Complex setup issues: sometimes bug like behaviours will be present in complex examples that people post. After a lot of investigation, I find that the answer was a simple setup issue that was hiding under layers of complexity.
Limitation hit: people hit against a documented limitation of the library. The limitation needs to be explained, and any relevant issues or documentation linked to. Sometimes this might lead to a new feature request issue being added, or additional detail added to an existing feature request.
Actual bug: actual bugs get raised and need to be fixed. I need to diagnose the bug, do a root cause analysis, design a solution, write a fix, write tests, merge the fix and do a release. Some bugs are simple problems with obvious fixes. Some expose much deeper issues. Sometimes I will release a short term fix if there is one available if I know that the correct fix will take a longer amount of effort. I will reproduce the provided example with a bug in a local environment to develop rbd against. Sometimes a bug can be fixed in an hour, sometimes two days. Sometimes it requires it change in architecture which might occur slowly over months.

Setup and limitation issues can also lead to documentation and development only warning improvements. Ideally, we make everything as clear as possible to people. I use repeating issues as a signal

Feature requests 🚀

rbd gets feature requests for a large number of interactions. These need to be run through our guiding principles and evaluated. Sometimes I think it fits into the direction of the library and keep the request open. This might be the start of a discussion as we figure out the implications and implementation details of the feature. Other times the request does not line up the direction of the project and I provide an explanation and close the issue. I might also add this information to the project philosophy page.

Discussions 🗣

We have a number of open discussion threads running at a time. This is for features and ideas that still require more thinking. These can be lengthy back and forth conversations and API, use cases, implementation, testing and implications. I often do a lot of background (shower) thinking about these.

Pull requests

We get about one pull request to the rbd project per week. There are a number of categories

Documentation fix: almost always can be easily merged
Proposed code changes: either a bug fix or new feature. Rarely created and even more rarely merged

Proposed code changes

The React team put it nicely when they said that rarely do they accept changes from external contributors. The React project has a rich history and established future direction. It is hard for an outsider to come in and make a meaningful contribution to the core library. I have found this also to be true for rbd. Changes on the fringes of the project are welcome and encouraged: documentation, build improvements, types, examples and (minor) bug fixes. But external contributors generally lack the context to make bigger changes. We do get some from time to time, but they often an attempt to meet their own goals without thinking more broadly about the library. I have found that these proposed changes are often in conflict with the accessibility or philosophy of the project. I generally encourage people to reach out before undertaking large engineering efforts to discuss what approach the change should take:

Hack: work with existing or new APIs to achieve their use case
Fork: maintain a forked version which bakes in their behaviour
Contribute: rbd could use the feature. In my experience, we have not had a single feature contributed entirely by an external. Sometimes I can shepherd through a bug fix. An additional challenge is their skill levels. On a few occasions, I have needed to rework big parts of external pull requests

Moderating 👩‍⚖️

There are 50+ active issues in rbd. They are comprised of feature requests, discussions, improvements and ideas. I monitor them to provide input and to ensure that the code of conduct is being observed. I try to respond to people within 48 hours. I also need to close old or redundant issues. I also get pinged questions through Twitter, Stack Overflow and other channels occasionally. I will either answer directly if it is simple or push them towards the project page to create an issue.

Sharing 🎁

There is some really interesting engineering in rbd. I write blogs and give talks to share my learnings and to market the rbd project. By doing this the impact of rbd is bigger than just the project itself. I will often spend 0.5-2 days writing a blog, 0.5-1 day preparing for speaking at a meetup and 3-5 days preparing for a conference talk. There is also a lot of thinking, exploring and discussions before creating sharable content.

Project related blogs

Performance related blogs

Sharing some of my performance engineering learnings from rbd

Talks

Deep sea fishing with React Hooks
Creating beautiful and accessible drag and drop for Atlassian
Rate limiting from scratch
What’s in the box?
React Portal: the good, the bad and the ugly
Dragging React performance forward
Performance optimisations for React: round 2
Performance optimisations for React applications
Performance hacking React
30+ at an internal Atlassian front end meetup

Internal Atlassian maintenance

All of the issue tracking and discussions for rbd is done on Github - so for the most, there are no double updates required for issues internally. However, there are internal rbd tasks as well. They include: creating and updating high level project tracking issues, meeting with internal stakeholders about future needs, internal blogs and planning discussions.

Closing thoughts

Maintaining rbd takes a lot of ongoing work. It is enjoyable to maintain a project with this scale - but it is heavy. Maintenance has been made easier by proactively pursuing self-service and continuing to engage with the project. In the times that I have needed to focus on other things, I know that the maintenance for the project has slipped as it is a fairly daunting domain to keep on top of.

I hope you have found this window into the maintenance cost of rbd insightful. Also a huge thanks to Atlassian for continuing to allow me to invest into rbd ✌️

DEV Community: Alex Reardon

Wait for pending: A Suspense algorithm exploration

TLDR

Background

'Wait for pending' algorithm

Example 1: Only siblings

react@18

react@19 alpha timing

Wait for pending

Example 2: With children

react@18 algorithm

react@19 alpha algorithm

Proposed algorithm

Closing thoughts

The Commute Rule

How to grow as a software engineer

Summary

Area 1: 👩‍💻 Technical proficiency

Master the fundamentals

Ask questions about your code

Understanding and balancing tradeoffs

Explore popular industry solutions

Bare the consequences of your choices

Version control

Area 2: 👀 Contextual awareness

Technical context

Team context

Business context

Industry context

Area 3: ✍️ Communication skills

Code authoring

Code reviews

Persuasion

General pointers

Pointer 1: You are worth more than your outputs

Pointer 2: Be kind to yourself

Pointer 3: Adopt a learners mindset

Pointer 4: Dangerous accelerant: side projects

Thanks

Gardening

Overhauling our collision engine

Problem 1: Knowing when to move

Solution: Flipping the logic

Problem 2: What is being dragged over?

Solution: Understanding intention

The new approach

Finding drop candidates 🙋‍♀️

Choose candidate that is furthest away

What does the new approach achieve?

Thanks

What does react-beautiful-dnd cost to maintain?

rbd is popular and much loved ❤️

The best defence is a good offence 🏈

Optimising for self-service

No open bugs 🐛❌

Rant 🌶

Workload 👷‍♂️

Bug reports 🐛

Feature requests 🚀

Discussions 🗣

Pull requests

Proposed code changes

Moderating 👩‍⚖️

Sharing 🎁

Project related blogs

Performance related blogs

Talks

Internal Atlassian maintenance

Closing thoughts

`react@18`

`react@19` alpha timing

`react@18` algorithm

`react@19` alpha algorithm

`rbd` is popular and much loved ❤️