Forem: Richard Oliver Bray

Why Shift+Enter doesn't work in Claude Code (and how to fix it)

Richard Oliver Bray — Fri, 06 Mar 2026 16:03:22 +0000

TL;DR

Enable the Kitty keyboard protocol in your terminal (WezTerm: add config.enable_kitty_keyboard = true to your wezterm.lua)
Open a new terminal window

If you've been using Claude Code and noticed that Shift+Enter just submits your message instead of adding a new line, you're not imagining things — it genuinely doesn't work out of the box. The good news is it's actually a one-part fix, and once you know why it's broken, it makes total sense.

Why it doesn't work

Claude Code does support a chat:newline action, but the reason Shift+Enter doesn't trigger it comes down to how your terminal handles key input.

Most terminals, by default, send the exact same byte sequence for both Enter and Shift+Enter. That means even though Claude Code is perfectly capable of inserting a new line, your terminal never actually tells it that Shift+Enter was pressed — it just sees Enter, and submits.

This is a known limitation of the traditional XTerm key encoding that most terminals use. The fix is to enable a newer keyboard protocol that can distinguish between modified keys.

The fix

Step 1: Enable extended key reporting in your terminal

This step depends on which terminal you're using. The key thing you need is support for the Kitty keyboard protocol.

If you've heard of the Kitty image protocol (which lets terminals display inline images), it's the same idea — a set of extensions to the traditional terminal protocol, created by the Kitty terminal, that other terminals have since adopted. Just like the image protocol adds capabilities the original terminal spec never had, the Kitty keyboard protocol adds the ability to send distinct escape sequences for key combinations that classic XTerm encoding can't distinguish — like Shift+Enter vs Enter.

So even though you might not be using Kitty as your terminal, you can still benefit from the protocol it introduced. Most modern terminals have added support for it.

WezTerm (this is the terminal I use and tested with):

Add this to your ~/.config/wezterm/wezterm.lua (or wherever your config lives):

config.enable_kitty_keyboard = true

Other terminals that support extended key reporting:

Kitty — enabled by default
Ghostty — enabled by default
iTerm2 — enable "CSI u" mode in Preferences → Profiles → Keys

If you're on a terminal that doesn't support any of these protocols, Shift+Enter likely can't be made to work without switching terminals.

Step 2: Open a new terminal window

This is the step that's easy to miss. The keyboard protocol is negotiated when a terminal session starts, so a config reload isn't enough. You need to open a new window (not just a new tab in the same session) for the change to take effect.

Once you do that, Shift+Enter should insert a new line exactly as you'd expect.

Conclusion

It's possible that the Claude Code team will add better handling for terminals that don't support extended key reporting in the future, which would make this post completely unnecessary. If that happens, this post will age badly — and honestly, that would be great. But for now, these are the hoops you need to jump through to get it working.

Why Rolldown-Vite Is Going To Replace Vite (And Why You Should Care)

Richard Oliver Bray — Wed, 11 Jun 2025 18:38:54 +0000

It feels like just yesterday I was writing about replacing Webpack with Vite, and here we are again with another potential game-changer in the JavaScript build tool ecosystem. The world of JavaScript tooling moves really quickly, and now there's a new development that could make your existing Vite projects build up to 16 times faster: Rolldown-Vite.

You can watch this article if you prefer video content.

If you've been following the JavaScript tooling space, you'll know that we've seen this cycle before. First there was Grunt then there was Gulp, then Webpack dominated for years (and still kind of does in some cases). Recently Vite has been the go-to choice for new projects. Now, the Vite team themselves are working on something that could supercharge the tool we already love.

What is Rolldown-Vite?

Rolldown-Vite is not a replacement for Vite itself. Instead, it's a Rust-based drop-in replacement for Vite's internal bundlers (ESBuild and Rollup). Think of it as Vite with a turbocharged engine under the hood.

Developed by Evan You (creator of Vue.js) and the VoidZero team, Rolldown-Vite uses the high performance of Rust to deal with bottlenecks in the current JavaScript-based Vite toolchain.

The numbers are very impressive:

A React project with 10,000 JSX components: 14 seconds with Vite → under 4 seconds with Rolldown-Vite (70% faster)
Excalidraw's build time: 22.9 seconds → 1.4 seconds
GitLab's build time: 2.5 minutes → 40 seconds

Understanding Vite's Current Architecture

To understand why Rolldown-Vite gives these performance improvements, we need to look at how Vite currently works:

Development: Uses ESBuild (written in Go) for fast bundling and transformations
Production: Uses Rollup (written in JavaScript) for final builds (I think)

While this setup has worked well for years, Rollup being written in JavaScript isn't the most performant option for building large-scale applications, especially in a CI/CD pipeline.

How Rolldown-Vite Changes the Game

Rolldown-Vite replaces both ESBuild and Rollup with a single, unified Rust-based bundler called Rolldown. This provides:

Consistent performance across development and production
Massive speed improvements thanks to Rust's performance characteristics
Reduced memory usage - crucial for large projects
Full compatibility with existing Vite plugins and configurations

At the heart of this is Oxc, a.k.a the Oxidation compiler which provides a parser*, for understanding JavaScript and TypeScript code. A **transformer for converting modern syntax to compatible versions. A resolver for handling module resolution. A minifier for optimising production builds, and a linter - for code quality checks.

Rolldown then uses Oxc as its foundational layer to provide the bundling functionality. This means instead of having separate tools for different tasks, everything runs through a single, highly optimized Rust-based pipeline.

The Rust Revolution Continues

There's definitely a pattern emerging in the JavaScript tooling space - everything is being rewritten in Rust. We've seen it with:

SWC (replacing Babel)
Turbopack (Webpack's successor)
RSPack and Farm (other bundling solutions)
Rolldown (now powering Vite)

Honestly, I'm not sure if I like (Golang FTW), it but it looks like things are going that way.

Rust provides the performance benefits that JavaScript simply can't match when it comes to intensive tasks like bundling, minification, and code transformation.

How To Switch?

The beauty of Rolldown-Vite is that it's designed as a true drop-in replacement. In most cases, you can try it by simply aliasing the Vite package to rolldown-vite in your package.json:

// package.json
{
  "dependencies": {
    // ...
    "vite": "6.3.5" // <-- before
    "vite": "npm:rolldown-vite@latest" // <-- after
  }
}

If you're happy with your current Vite setup and build times aren't an issue, there's no urgent need to switch. I mean, for me Vite has always been super fast.

But, if you're working on larger projects where build times are becoming a bottleneck, Rolldown-Vite can provide significant improvements with minimal effort.

Understanding and Preventing Fetch Waterfalls in React

Richard Oliver Bray — Thu, 02 Jan 2025 20:38:39 +0000

If you're a React developer, it's a safe bet you've encountered fetch waterfalls - also called request waterfalls or network waterfalls. Their distinctive shape crops up in analytics tools when you go try to see what's taking the page you painstakingly designed is taking so long to load.

In this blog post, we’ll go into what fetch waterfalls are, why they happen, how they affect your React applications, and, most importantly, how to avoid them.

What is a Fetch Waterfall?

Let’s start with the basics.

A fetch waterfall is a performance issue that occurs when multiple API calls or fetch requests are chained together and executed one after another. Rather than sending multiple requests in parallel (which would allow them to complete concurrently), the requests are queued and executed in sequence. This results in significant delays in page rendering, especially if the number of fetches increases.

Here's a simple visual representation of what this looks like:

Source: Sentry.io

From the image above, you can clearly see the sequential delays in a 'waterfall' pattern. Each request starts only after the previous one has finished. In practice, even a slight delay in one request can cause the entire page load time to increase dramatically.

This is particularly troublesome for user experience, as modern web users expect fast-loading applications. A few seconds of delay can lead to higher bounce rates and lower engagement, impacting your application's overall success.

Why Do Fetch Waterfalls Happen?

Fetch waterfalls in React typically occur due to the hierarchical structure of components. Here’s a typical scenario:

Parent Component Fetches Data: The parent component initiates a fetch request when it mounts.
Child Components Await Data: Child components rely on data fetched by the parent and are rendered only once the parent’s data is available.
Sequential Requests: If there are multiple nested components, each one might trigger fetch requests sequentially, causing a "waterfall" effect.

This cascading behavior occurs because components in React render asynchronously. When the parent component fetches data, child components may have to wait until the parent’s request is completed. If these fetches are not handled efficiently, you can end up with a significant delay as each request depends on the previous one.

How to Identify Fetch Waterfalls

To identify if your React application is suffering from fetch waterfalls, you can use tools like Chrome DevTools or React DevTools to monitor network requests and performance. In Chrome DevTools, navigate to the Network tab and look for sequential API calls that are blocking the page’s loading process.

In React DevTools, you can inspect component re-renders and identify any unnecessary dependencies causing fetch requests to be triggered multiple times.

Here are some signs that a fetch waterfall may be occurring:

Slow page load times: If your page takes longer than expected to load.
Suspicious performance patterns: If you notice a series of API calls that appear to be made one after another instead of in parallel.

How to Prevent Fetch Waterfalls in React

Fortunately, there are several strategies to avoid fetch waterfalls and optimize your React applications for better performance.

1. Fetch Data in Parallel

Instead of waiting for each API request to complete before starting the next one, consider executing multiple fetch requests in parallel. This can be done using JavaScript’s Promise.all() method, which allows you to run multiple promises concurrently.

Here’s an example of fetching data in parallel:

const fetchData = async () => {
const [data1, data2, data3] = await Promise.all([
  fetch('/api/data1').then(res => res.json()),
  fetch('/api/data2').then(res => res.json()),
  fetch('/api/data3').then(res => res.json()),
]);
// Use the data
};

By fetching data in parallel, you reduce the total waiting time and allow the browser to load resources faster.

2. Decouple Component Data Fetching

You can refactor your components so that they don't rely on the parent component’s data to trigger their own fetches. Instead, let each child component handle its own data fetching independently. This can be done by lifting state up and passing down the necessary data or by using libraries like React Query or SWR to manage fetching at the component level.

3. Use React Query or SWR

Libraries like React Query and SWR are great for managing data fetching in React applications. They handle caching, background data fetching, and error handling, while also allowing you to fetch data in parallel efficiently.

React Query, for instance, automatically handles caching, retries, and background syncing for data fetching, ensuring that your components don’t unnecessarily wait for data and that network calls are only made when needed.

import { useQuery } from 'react-query';
const fetchData = async () => {
const res = await fetch('/api/data');
return res.json();
};

const MyComponent = () => {
const { data, isLoading } = useQuery('dataKey', fetchData);

if (isLoading) return <div>Loading...</div>;

return <div>Data: {JSON.stringify(data)}</div>;
};

4. Cache Data to Reduce Redundant Requests

Caching can significantly reduce the need for redundant requests to the server. By storing fetched data locally (in the component state, context, or a caching library like React Query), you can avoid unnecessary network requests, making your application faster and more efficient.

Conclusion

Fetch waterfalls in React can be a major source of performance bottlenecks, but with the right strategies, they can be easily avoided. By fetching data in parallel, decoupling data fetching from components, and leveraging powerful libraries like React Query, you can improve the performance of your React applications and enhance the user experience.

If you're dealing with frequent fetch waterfalls in your React codebase, it's worth taking a step back to analyze your data fetching patterns and implementing these best practices. Ultimately, optimizing how your application interacts with APIs will result in faster, more reliable, and scalable applications.

Crafting a Captivating CV: The Secret to Standing Out as a Software Engineer in 2024

Richard Oliver Bray — Tue, 09 Jan 2024 17:24:36 +0000

Getting a job as a software engineer in 2024 is going to be tough. Not only have a lot of good developers been laid off but companies are hiring less in general. So what can you do to stand out from the crowd?

Learn some new skills, practise data structures and algorithms or write an outstanding CV? If you do the first two things but have a terrible CV, you're not going to get an interview, so in my books, it makes sense to start with the CV.

So in this article I'm going to talk about 5 things you can do to write a better CV and get more interviews.

Shameless Plug

I've created an online course to help you write the best possible software engineer CV which you can get access to here.

If you enjoy this article I highly recommend you check it out.

1. Have a One Page, Single Column CV

Your CV should be just one page long. Not two, not one and a half, but one page. The person reading your CV doesn't have time to dig through two pages of information to find what they're looking for.

The person who is going to review your CV is only going to look at it for an average of 6 to 8 seconds therefore just the important information, so skills, experience and qualifications, should be able to fit on one page. And if it can't, then that means you may have to cut some things out. You could have one or two columns in your CV. And for the most part, it doesn't really matter. But, in my opinion, it's much easier to read a single column CV than a two column CV.

And if the aim is to make it as easy as possible to read, for the person going through your CV to find the information they're looking for, then a single column CV is the way to go.

2. Focus on Skills, Experience and Education

In the 6 to 8 seconds a hiring manager or recruiter is going to spend reading your CV, they're going to be looking for these three things. 1. Do you have the skills they're looking for? 2. Do you have the experience they're looking for? And 3. Do you have the qualifications they're looking for? Skills, experience and qualifications.

This is how you should structure your CV. You have to put these things at the forefront so that they're easy to find. If a person looking at your CV can't find these things easily, say in 6 8 seconds, then they're going to move on to the next CV. And yours will be one of the 80 percent that get rejected.

At the top of your CV you should have your name, address, GitHub, LinkedIn, websites, telephone number, etc. Then, right underneath you need to have a section called Skills. You can put technical skills, but I like the word skills because it's really easy to read and find.

In this skills section, you should list all the skills you have that are relevant to the job. So if you're a front end developer, list all the languages and frameworks that you know. So things like React, JavaScript, CSS, Angular, etc. List them all in the Skills section.

A recruiter would come here first and see if your skills match the skills that they're looking for and if they do match, then they'll move on to the next section which should be experience. You can call it Work Experience but to keep things simple I like having sections with one word so just Experience is fine.

The most recent job or piece of experience should be at the top and the oldest one should go at the bottom. If you've never had a job, then you can change this experience to projects and you can list all the projects that you've worked on in your bootcamp or in your spare time. I would say however, it's really important to try and get some experience if you don't have any.

I'm planning to write an article on how to get experience without a job in the future but if you can't wait till then, I've outlined exactly how to do it in my CV course.

Each piece of job experience you should have no more than five bullet points, and the more you go down, the less bullet points you should have. Then below the experience section, then, you should have a section called education.

This could also be qualifications. But as long as it's one word, I'm okay. This should contain the highest qualification you have related to software engineering. And the qualification should just have one bullet point.

3. What You Did, Why You Did It and The Results

This is one of the most important parts of this article. If you take no other advice away, then please take the advice from this point, this alone could make a huge difference to your CV. Whenever you're writing bullet points for the experience part of your CV, you need to follow this formula. What did you do? Why did you do it? And what was the outcome?

Why did you do it? And what was the outcome? Let's go through a quick example.

Imagine a bullet point in the experience section under a specific job is;

'Built a website using React and Node.js'.

This at the moment is not that good. It tells the employer what you did, but it doesn't tell the employer anything else. Any developer could have done this so what makes you doing it so special? Let's look at how this can be improved.

'Built a website using react and Nodejs To help people find jobs'.

This is better. We've added the why we're helping people find jobs, but how many people have we helped? Basically, what was the outcome? Let's see how this can be rewritten.

'Designed and developed a web application using React and Node.js to help people find tech jobs. This application helped 50 to 100 people find jobs every month.'

This is much better. You can read what was done, we can see why it was done and the outcome.

No jargon, no slang and no personal pronouns. So don't use words like I, it's implied that you did it. Keep it short, as simple as you can and make it sound professional.

4. Use a PDF

What format should your CV be in? Simple answer is PDF. Not a Word document, not a Google Doc, not pages or anything else. Just a PDF. The recruiter or hiring manager might have a different version of Word than what you use to create the CV. Therefore, if they open it, the layout could be messed up. And also, Documents can look different on different operating systems.

So if you wrote your CV on a Linux machine, and the person receiving it is using a Windows then there might be some issues with formatting and compatibility. But a PDF will look the same on any machine, no matter the version or operating system. So in my opinion, it's the safest option to use.

If we have a look at the image above, this is an image of someone who created their CV using a Word document, and they put boxes all over it. But when the recruiter opened it, this is what they saw. The layout and the formatting had been distorted so much that it was completely impossible to read.

Please don't let that be you. Just use a PDF for your CVs all the time.

5. Don't add a Hobbies or Interests Section

Instead of writing a list of hobbies and interests, you can replace that whole section with a list of achievements you've had using the what you did, why you did it and what was the outcome technique, let's try it. So imagine this specific bullet point was in the hobby section of a CV:

"I like to play football."

Now, in my opinion, this is a terrible way to add a hobby to your CV. It doesn't give the employer any indication of how good you are and why you like playing football. Let's see how this hobby can be rephrased.

"Play as a goalkeeper for my local team and have won the league three times."

This is a bit better. It tells the outcome and what you do, and shows the employer that you have teamwork skills and dedication, since not everyone can play football long enough to win the league, especially three times. Again, let's see how this bullet point can be improved.

"Regularly play as a goalkeeper for my local team, London Lions, to maintain fitness, contributed to winning the league three times in the last five years."

This is much better, and this is what you should be aiming for when you're adding your hobbies. This contains the what, the why, and the outcome. And it sounds much more impressive than the first version.

This is what you can do to turn just any hobby into an achievement. And this is why I highly recommend you do not have a Hobbies or Hobbies and Interests section. Instead, turn those around into an Achievements section and this will make you look much more impressive in the eyes of an employer.

To Wrap it All up

So there you have it, five things you can do to write a better CV and get more interviews. Weather you're a junior developer frontend developer or a senior developer fullstack developer, these tips will be sure to help you out.

If you want to learn more about how to write a better CV, again check out my online course that goes into a lot more detail than this article. I've put a lot of work into this talking to recruiters, hiring managers and combining it with my own experience, so be sure to check it out.

Until next time. Happy coding 👋

You've been structuring files in projects wrong

Richard Oliver Bray — Wed, 19 Oct 2022 15:14:58 +0000

Originally posted here https://medium.com/octopus-labs-london/how-to-structure-files-in-large-react-projects-48ee3dc424ed

Okay I admit, I've got your attention with a somewhat catchy title but hear me out.

When you tend to have large React, Svelte, Vue, any frontend framework (or library) project, it's easy to put all the components in a components folder, containers in the containers folder and so on. Well I have a different approach for really large projects. Something that looks a bit like this

public/
package.json
index.ts
src/
│
├── components/
│   ├── Button/
│   │   ├── Button.tsx
│   │   ├── Button.tests.tsx
│   │   └── Button.css
│   ├── Dropdown/
│   ├── Toaster/
│   ├── Header/
│   └── Footer/
│ 
├── layouts/
│   └── StoreLayout/
│       ├── components/
│       │   ├── SearchDropdown/
│       └── StoreLayout.tsx
│ 
└── pages/
    ├── StoreProductPage/
    │   ├── components/
    │   │   ├── Carousel/
    │   │   └── ProductCard/
    │   └── StoreProductPage.tsx
    │
    └── StoreCheckoutPage/
        ├── components/
        │   └── ProductCheckoutCard/
        └── StoreCheckoutPage.tsx

This way it's easy to remove pages without other parts of the site. All the general components go in the components folder. But Page specific components go in a sub-folder.

Not quite convinced?

Check out my video explanation on YouTube.

Let's talk

It would be good to hear your thoughts on this approach, if you like or dislike it, and if you have any ideas for improvements. You can find me on the socials, or you can just write a comment below and I promise I'll respond 🙏

Application specific preferences on my Mac have gone 😱

Richard Oliver Bray — Sat, 15 Oct 2022 12:47:27 +0000

A few weeks ago I head a problem with my applications where whenever I changed a setting they were not saving, or the settings had just reverted to their default. My VSCode, ZSH, mechanical keyboard settings had all gone.

After hours I managed to figure out the issue and I've created a video below to show how I did it.

How to use hooks in React Class components

Richard Oliver Bray — Mon, 11 Apr 2022 16:44:49 +0000

You're probably thinking, why on earth would anyone want to use a hook in a class based component, two words, legacy projects.

Hooks are cool and so are functional components, but if you're working on a 4 year old project that has loads of class-based components, you don't have the time to convert them to function based components. What's more, loads of newer libraries only use hooks.

So if you want to keep a legacy project up-to-date, this is a really helpful technique.

The code

import { Component } from 'react';
import { useNavigate } from 'react-router-dom';

class Login extends Component {
  render() {
    return (
      <>
        <p>My awesome component</p>
        <button type="button" onClick={() => this.#handleClick()}>
          Click here
        </button>
      </>
    );
  }

  #handleClick() {
    this.props.navigate('/dashboard');
  }
}

function addHookTo(Component) {
  function CompWithHook(props) {
    const navigate = useNavigate();

    return <Component {...props} navigate={navigate} />;
  }

  return CompWithHook;
}

export default addHookTo(Login);

Aaaaand that's it!

Credit where credit is due

I could take all the credit and say my clever mind figured all this out but I actually saw it on the React Router website here -> https://reactrouter.com/docs/en/v6/faq#what-happened-to-withrouter-i-need-it

They have a good example on there of adding multiple hooks.

Anyway, I hope you found this useful.

How to replace webpack & babel with Vite on a legacy React TypeScript project

Richard Oliver Bray — Fri, 25 Mar 2022 14:37:28 +0000

It's insane how fast the world of JavaScript moves.

As far as build tools go I remember how popular Grunt was when it was first released, then it was Gulp, and Babel came along to help you add new us features and get them working on older browsers.

Then there was Webpack which seemed like it would be around for a while. Even after things like Parcel and Snowpack came on the scene people still recommended Webpack. I mean, it's still the backbone of create-react-app. An then, Vite was released.

Vite is fast, really fast. It requires very little config and is easy to setup. It sits on top of esbuild.

I have no doubt there will be something in the future that will replace Vite, but for the simple fact that the config file for Vite can be around 10 lines whereas for Webpack it would have been around 100, I think it's a good choice to stick with for the next few years and something to upgrade your old Webpack project to.

Plus you don't need Babel if you're using Vite so you can get rid of a tonne of dependencies and security vulnerability messages.

Main steps

1 - First thing's first, let's create a new branch for our old project just in case we need to go back to it for any reason. We can delete the branch after a few months if we've never needed to refer to it.

# oh-my-zsh git aliases
gcb old-webpack-babel
gpsup

Note: The above commands are aliased github commands that come by default with oh-my-zsh. You can view the full list here.

2 - now let's go back to our main branch and remove all of our babel and webpack packages, brace yourself for one large command:

npm uninstall webpack webpack-merge webpack-dev-server
 webpack-cli ... you get the idea

3 - Delete all webpack and babel related files, webpack.common.js, webpack.dev.js etc...

4 - Install Vite and the Vite React plugin

npm i vite @vitejs/plugin-react
# then
npm i @types/node -D

5 - Create a vite.config.ts file in the root of your project with the following code:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()]
});

6 - Update your package.json file with the following code

"dev": "vite",
"build": "vite build",

And now run npm run dev, and if all goes well your project should be fine.

Optional steps

Depending on your project, the steps below might not be necessary.

Aliases

If like me you have some random Webpack aliases in your code like this:

import "@/assets/styles/global";

You can add that to your Vite config file like so:

// At top of file
import path from "node:path";

// ...
  resolve:{
      alias:{
        '@' : path.resolve(__dirname,)
      },
    },
  plugins: [react()]

CSS Modules

If you're using css modules, then I feel sorry for you. You need to change the extension of all your files to .module.css instead of just .css

Then change the name of any compose properties you have in your css file as well:

/* from this */
composes: c-white from "../helpers.css";
/* to this */
composes: c-white from "../helpers.module.css";

And also any JS/TS file that you are importing the css file in.

// from this
import buttonCss from '@assets/styles/Buttons.css';
// to this
import buttonCss from '@assets/styles/Buttons.module.css';

This is really painful I know, but it does kind of make more sense. And also, find and replace all is your friend 💪

Vite environment variables

You may want to set up environment variables to keep secrets or to insert bits of information based

1 - Create a .env file.
2 - Put a VITE_ prefix in front of variables like this:

VITE_TEST_VAR = "something secret"

3 - Load them up in your code like this:

const secretVar = import.meta.env.VITE_TEST_VAR;

4 - If you're using Typescript you will need to create an env.d.ts file in the root of your project

/// <reference types="vite/client" />

interface ImportMetaEnv {
  readonly VITE_APP_TITLE: string
  // more env variables...
}

interface ImportMeta {
  readonly env: ImportMetaEnv
}

Install npm-check-updates

Since you're upgrading one part of a legacy project, why not update all the other dependencies. The best way to do that is with the npm-check-updates package.

I'd recommend installing updates in by semver levels, so patch updates first, then minor updates, then major. Testing the project still works in-between updates

This can be done easily by running a command like this:

ncu -t patch -u

to update just the patch versions in the package.json file, then run

npm i

to actually install the updates.

And that's pretty much it.

I'm not expert on Vite but if you have any questions, feel free to write them down in the section below and I'll do my best to answer them.

Fix sameSite cookie issue in Cypress by installing an older version of Chromium

Richard Oliver Bray — Tue, 01 Mar 2022 16:26:11 +0000

Cypress out of the box doesn't allow you to visit different urls or domain from the base one in a given test. You can read more about that in the Cypress documentation on web security.

To get around that the following option can be for Chromium based browsers in the cypress.json file:

{
  "chromeWebSecurity": false
}

This works great for most scenarios, but if like me, you're running a test suite that relies on putting cookies from one domain onto another, then you might face a problem.

Why would a site need to share cookies between domains?

This is quite common for passing information from one site to another or session information. If the cookie has expired it means the session has ended and the user cannot do much on the new site they've visited unless the get a new cookie from the previous site.

This doesn't work in newer version of Cypress although it did work in older version. Since Chrome 80 the SameSite attribute needs to be specified in cookies to declare how restrictive they should be. Before Chrome 80 SameSite=None was on all cookies by default but now it needs to be explicitly added in the API request or it's defaulted to SameSite=Lax.

This means running this test suites that require cookies to be shared between domains won't work:

Unfortunately newer version of Chrome (94+) have also removed the flags to disable this. The only way around this issue is to install an older version of Chromium where disabling SameSiteByDefaultCookies is possible with a flag.

Here's how that can be done.

1 - Visit the Cypress chromium downloads site

2 - Find the latest stable version for 90 and download it for your relevant Operating System

NOTE: In theory any version below Chromium 94 should work but I only tested with 90 so that's why I'm recommending it.

3 - Unzip the file and place the contents in an easily accessible location

NOTE: I'd recommend contents of this folder not be pushed to somewhere like GitHub

4 - Open the browser you just downloaded and make sure you adhere to all the security requirements of your relevant operating system.

5 - We'll now need to add some code to the cypress/plugins/index.js. The code is an addition to this excellent solution from poponuts:

const path = require('path');

//...

function addChromiumBrowser(config) {

    const fullChromiumPath = path.resolve('cypress/browsers/chrome-90-mac');
    const chromiumOptions = {
        name: 'chromium',
        channel: 'stable',
        family: 'chromium',
        displayName: 'Chromium',
        version: '90.0.4430.93',
        path: `${fullChromiumPath}/chrome-90-mac/Chromium.app/Contents/MacOS/Chromium`,
        majorVersion: 90,
    };

    config.browsers.push(chromiumOptions);
}

module.exports = (on, config) => {
    on('before:browser:launch', (browser, launchOptions) => {
        if (browser.name === 'chromium') {
            launchOptions.args.push(
                '--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure'
            );
            return launchOptions;
        }
    });

    addChromiumBrowser(config);

    return config;
};

NOTE: If you are using a version of Chromium other than 90, please change the version and majorVersion fields as well

6 - If all went well, running npx cypress open Should reveal a new browser in your list.

Running in Chromium should fix whatever issue with SameSite cookies you have in Cypress.

Sources

https://dev.to/poponuts/overcoming-samesite-cookie-issue-in-cypress-when-running-on-chrome-or-edge-274m
https://digitaldrummerj.me/cypress-custom-browser/

Why the VAR and LET keywords shouldn't be used interchangeably

Richard Oliver Bray — Thu, 13 Jan 2022 21:07:19 +0000

If you'd asked me about the var and let Javascript keywords about a week ago I would say for the most part, they are interchangeable. Yes var is function scoped and let is block scoped but I really ran into a situation where switching them around caused any issues. Until recently...

A friend of mine show me this piece of code:

function fn() {
  for (var i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 1000 * i);
  }
}
fn();
// >>>>> Output <<<<
// 3 (immediately)
// 3 (after one second)
// 3 (after two seconds)

---

function fn() {
  for (let i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 1000 * i);
  }
}
fn();

// >>>>> Output <<<<
// 0 (immediately)
// 1 (after one second)
// 2 (after two seconds)

I assumed it would loop though 0-2 with both keywords but I was shocked to see it only did that when let was used and not var. At the time I had no idea why that was the case so I did some research and thought I'd put my findings in a post for others to learn from.

To fully understand why this happens we need to talk about two things; scope and the event loop.

1. Scope

The var keyword has function level scope and the let keyword has block level scope, but what does that actually mean?

Scope in most programming languages refers to the access functions and objects have to variables depending on where they are placed. There is a great video by LeanCode.academy that explains the details of what scope is, but for the code I shared above, when the var keyword is used, it can be read and reassigned outside of the loop within the fn function. When let is used, it cannot be read or reassigned outside of the loop even within the function.

2. The event loop

Javascript is a single-thread language, I won't go into detail on what that means in this post, all you need to know is that it can't execute multiple things at the same time. However, with the power of the event loop Javascript can give the illusion executing multiple things by putting some code aside and coming back to it later, when this happens really fast it sort of feels like multiple things are running at the same time. This is how the setTimeout function works.

There's a great video by Philip Roberts that explains in detail how the event loop works but for this post I'm going to simplify it a bit for our case.

Javascript code in the browser is placed in the call stack before being executed. If the code needs to be executed later (if it's a promise or setTimeout etc...) it is handled by some browser APIs (which we won't talk about in detail), before going into the task or event queue. The event loop is constantly checking if the call stack is empty, if it is, it will add an event from the event queue to the call stack to be executed. Let's go through our code with the event loop in mind.

a. When our code first runs it adds our main function (fn), then the loop to the call stack. This happens for both let and var versions:

b. The first setTimeout is reached then added to the call stack, but then moved to the browser APIs to be handled later.

c. The first setTimeout has an instruction to execute after 0 milliseconds (1000 * i where i is 0 on the first loop). So that immediately get's sent to the event loop and will stay there until the call stack is empty.

d. The loop will run two more times and move the following setTimeout functions from the call stack to browser APIs with instructions to execute after 1000 and 2000 milliseconds respectively.

e. After that's done the loop and the main function are popped off the call stack, the event loop checks if there's anything in the event queue and since there is, that get's moved to the call stack.

f. At this point the first setTimeout function will run and i will be set at the time this executes.

Bear in mind that the loop has already run three times at this point, so when var is used by the time this executes i is equal to 3, why? The first time the loop runs i is 0, then 1, then 2. Because var is function scoped it will increment from 2 to 3 and then not run the loop.

In the case of let however, because it is block scoped, even after the loop has run three times when this setTimeout executes, the value of i is 0, it hasn't been reassigned.

g. The next setTimeout function moves to the event queue after 1000 milliseconds then with the help of the event loop quickly moves into the empty call stack and executes. Again at this stage if the var keyword is used i will equal 3, but for let when the console log runs it looks for the block scoped value of i is 1, this was retained when this event was first moved from the call stack to the browser api so that will print 1 to the console.

You've probably figured out what happens to the last setTimeout function so I won't go through that.

If you add a breakpoint to the function in the setTimeout and look in the Chrome dev tools the difference between function and block scoping is a tiny bit more obvious.

var shows the function scoped variable in the main function (fn), but let shows the loop (_loop_1) inside the main function which is the extra bit of information saved in the event that goes through the event loop remembering the block scoped value of the variable.

Final words

I know this post is quite long but I hope you found it useful. Whenever you can, use let instead of var . If you can't, there ware ways of getting block scoping with var but it results in some weird looking code:

function fn() {
  for (var i = 0; i < 3; i++) {
    ((i) => setTimeout(() => console.log(i), 1000 * i))(i);
  }
}
fn();

Happy coding 🧑🏿‍💻

Sources

https://www.outsystems.com/blog/posts/asynchronous-vs-synchronous-programming/
https://www.educative.io/edpresso/what-is-an-event-loop-in-javascript
https://stackoverflow.com/questions/31285911/why-let-and-var-bindings-behave-differently-using-settimeout-function

How to fix the ReferenceError: global is not defined error in SvelteKit/Vite

Richard Oliver Bray — Fri, 03 Dec 2021 18:10:29 +0000

TL:DR

// svelte.config.js
const config = {
    preprocess: preprocess(),
    kit: {
        adapter: adapter(),
        target: '#svelte',
        // add this 👇
        vite: {
            define: {
                global: {}
            }
        }
    }
};

I spent hours trying to figure this out and it was really difficult to find the exact information on the web since this error message is very similar to an Angular issue. However, the Angular solution is useless for SvelteKit so, I thought I'd put this post together.

SvelteKit is currently in beta so who knows, maybe they might address this at some point in the future but anyway...

SvelteKit uses Vite as its build tool which is great because Vite pre-bundles dependencies using esbuild which is really really fast. But by default, Vite doesn't include shims for NodeJS variables so these need to be added by the user.

That sound simple enough to fix, just create a vite.config.[js/ts] file, add it to your SvelteKit project and define global right?

// vite.config.ts
export default defineConfig({
  define: {
    "global": {},
  },
});

Well not quite...

This would usually be fine but SvelteKit doesn't play ball with a Vite config file, it will instead ask you to put the changes in a svelte.config.file. Makes sense I guess🤷?

Apart from the fact that a svelte config looks different from a vite config so it's not as simple as just copying and pasting into the main config object. Following the link in the error take you here -> https://kit.svelte.dev/docs#configuration-vite which isn't super useful. But after a bit of googling I found this much more helpful example albeit on a different topic but it was good enough.

And... that's what lead to the working solution below:

// svelte.config.js
const config = {
    preprocess: preprocess(),
    kit: {
        adapter: adapter(),
        target: '#svelte',
        // add this 👇
        vite: {
            define: {
                global: {}
            }
        }
    }
};

I should also mention I'm quite new to Svelte so there is a huge chance someone will call me out in the comments and add a much more elegant solution 😜

Sources

https://github.com/vitejs/vite/issues/2778
https://github.com/vitejs/vite/issues/728
https://github.com/bevacqua/dragula/issues/602
https://kit.svelte.dev/faq#aliases

Type conversion in Rust (as, From, and Into)

Richard Oliver Bray — Fri, 15 Jan 2021 13:47:18 +0000

I'm fairly new to Rust and it's a language I've actually enjoyed learning, mainly for game development with Bevy. As someone who is coming for a JS/TS background, there is a huge learning curve and I'm eventually planning to create a video course on how to make a simple game with Rust, but for now, I'm going to document things down (in the form of dev.to articles) as and when I learn them to help people who are having difficulties.

This particular feature of Rust is something I've seen a lot in Bevy example code particularly when it comes to colours, for example:

materials.add(Color::rgb(0.7, 0.7, 0.7).into())

The .into() method is something that I've scratched my brain over for ages and I've finally been able to figure out what it does. Well, at least I think I have.

as

Simple (explicit) type conversion or casting in Rust can be done with the as keyword:

fn main() {
  let num:u8 = 10;
  let multiplied = times_ten(num as f32);

  println!("{}", multiplied); // 100
}

fn times_ten(val: f32) -> f32 { 
  val * 10.0 
}

From

From in Rust is one of two traits for type conversion (if you don't know what a trait I'm planning to write a post on it in the future).

Let's say I want to create my own special type called MySpecialNumber and want to convert an existing u32 variable to my custom type, I would do it like this:

#[derive(Debug)] // needed because struct displays nothing so needs to have a debug view
struct MySpecialNumber(u32);

impl From<u32> for MySpecialNumber {
  fn from(num: u32) -> Self {
    MySpecialNumber(num)
  }
}

fn main() {
  let existing_var = 30;
  let num = MySpecialNumber::from(existing_var);
  println!("{:?}", num); // Prints -> MySpecialNumber(30)
}

If this is the first time you've seen the struct or impl keyword again, don't worry. I'm planning to cover those in future posts. They're a bit, different if you're coming from Javascript, you can think of them as a slightly more complicated way of making an object.

The above code snippet takes the existing_var of type u32 and changes it to type MySpecialNumber using the from method written above.

Because the From method is extending a trait it has to be written in a very specific way for it to work. If I changed the line fn from(num: u32) to fn from(num: f32) it wouldn't work. The source code for the From trait can be found on the Rust Github repo.

Into

Into is the second trait in Rust used for type conversion. It works in the opposite direction to the From trait, instead of creating x FROM y, it turns y INTO x, makes sense? It's a bit confusing right. I feel like code is the best way to explain things so let's jump straight into it (no pun intended).

First way to use Into

If there's an implementation of the From trait already we can also use the Into trait which is pretty cool.

To use into the main function of the above code snipped can be re-written as:

...

fn main() {
  let existing_var: u32 = 30;
  let num: MySpecialNumber = existing_var.into();
  println!("{:?}", num); // Prints -> MySpecialNumber(30)
}

Arguably this was is more readable. The existing_var is being converted to MySpecialNumber because it has been added as a type annotation. If that get's removed Rust won't know what type to convert the existing variable to.

let num = existing_var.into(); // this won't work

If you really wanted to, you could write a full Into method similar to the way I wrote the From method above using the Into that from the Rust source code, but I think From is good enough.

Second way to use Into

For this way we're going back to my times_ten function I used above when desiring the as keyword.

fn main() {
  let num:u8 = 10;
  let multiplied = times_ten(num as f32);

  println!("{}", multiplied); // 100
}

fn times_ten(val: f32) -> f32 { 
  val * 10.0 
}

Instead of using as we can use the Into trait like so:

fn main() {
  let num:u8 = 10;
  let multiplied = times_ten(num);

  println!("{}", multiplied); // 100
}

fn times_ten<T: Into<f32>>(val: T) -> f32 { 
  val.into() * 10.0 
}

So if you compare the last two code snippets, you'll see we can omit the as keyword and the type to convert to and move that logic to the times_ten function in the form of a generic data type T and the Into trait.

No matter what type the argument is that is passed into the times_ten function it will always be converted fo an f32 before it is multiplied by 10.

Don't worry if this doesn't make sense now, the more you use it, the more sense it will make.

Like I said at the beginning I'm new to Rust so there's a chance I haven't explained something properly or I've missed something out when it comes to type conversion then please let me know.

I've tried my best to explain this in the simplest way possible but if something I've said doesn't make any sense, again please let me know.

Sources

https://doc.rust-lang.org/rust-by-example/conversion/from_into.html
https://www.youtube.com/watch?v=vH5xXr81a2Y
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c749b272a173bfb34371092c562551fa