Forem: Bionic Julia

Creating a React Accordion Component Using Just CSS

Bionic Julia — Sun, 08 May 2022 00:00:00 +0000

About a year ago now, I wrote a blog post on how to create an accordion component in React with Typescript and TailwindCSS. I recently needed to implement an accordion component again (this is why keeping a blog is so handy!), but this time in a codebase that doesn’t use TailwindCSS. Here’s a short follow-on to that post for how you’d create an accordion component if you were just using straight CSS. I'd recommend reading that post first if you're new to React, as it includes more detail on the order in which I built up the code.

Note that I’ve left most of the styling of the overall component out and focused on the important ones that effect the transition.

import React, { MutableRefObject, useRef, useState } from 'react'
import { appConfig } from '../appConfig'

interface AccordionProps {
  title: React.ReactNode
  content: React.ReactNode
}

export const Accordion: React.FC<AccordionProps> = ({ title, content }) => {
  const [showExtraContent, setShowExtraContent] = useState(false)
  const [height, setHeight] = useState('0px')

  const contentSpace = useRef(null) as MutableRefObject<HTMLDivElement>

  function toggleAccordion() {
        setShowExtraContent((previousState) => !previousState)
    setHeight(showExtraContent ? '0px' : `${contentSpace.current.scrollHeight}px`)
  }

  return (
    <div className="container">
      <button
        onClick={toggleAccordion}
      >
        <p>{title}</p>
        <img
          src={'/assets/img/icons/chevron-up.svg'}
          alt="Chevron icon"
          className={`${showExtraContent ? 'rotate' : null} arrow`}
        />
      </button>
      <div
        ref={contentSpace}
        style={{ maxHeight: `${height}` }}
        className="extra-content"
      >
        <div>{content}</div>
      </div>
    </div>
  )
}

Here are the corresponding CSS styles.

.container {
  display: flex;
  flex-direction: column;
}

.arrow {
  transition: 0.3s;
}

.rotate {
  transform: rotate(180deg);
}

.extra-content {
  overflow: hidden;
  transition: max-height 0.3s ease-in-out;
}

Like this post? Read more from me at https://bionicjulia.com/blog.

Using AMP Images in NextJS

Bionic Julia — Sat, 30 Apr 2022 00:00:00 +0000

AMP - Accelerated Mobile Page

First things first, what is AMP? It stands for Accelerated Mobile Page and is a web component framework that allows us to easily create user-first experiences for the web. It’s an open-source project by Google and Twitter, and was designed to create really fast mobile pages. If you want to read more about it, check out the official website.

How NextJS integrates AMP

NextJS makes it easy to integrate AMP components in your app, with an advanced feature that’s easily configurable. You can set the configuration on a page by page basis, deciding whether you want each particular page to be an AMP-only page (if the page has no NextJS or React client-side runtime) or a hybrid page (where the page will be rendered as traditional HTML by default, but where you can render AMP HTML by adding ?amp=1 to the URL).

If you’re coding up a hybrid page, NextJS provides a nice useAmp hook to allow us to differentiate between the two modes. This allows us to create conditional JSX for instance, whereby if useAmp returns true, we render an AMP component, and a normal HTML element if otherwise. Read more about how to set this up in NextJS here.

amp-img component

The AMP component I want to focus on today is the amp-img component. Images can really add to the feel and messaging of a web page...but at the cost of potentially slowing load times. The other potentially annoying thing is cumulative layout shift as images are loaded and rendered, which Google heavily penalises. AMP images can really help on both of these counts, as it smartly manages image resources during runtime, and additionally, places images in their rightful place to limit layout shift, due to the fact that we need to pass in an image’s explicit size.

If you want to make a hybrid AMP image component in NextJS, it could look something like this.

import React from 'react'
import Image from 'next/image'
import { useAmp } from 'next/amp'

export const ImageWithAmp = ({ src, alt, width, height }) => {
  const isAmp = useAmp()
  return isAmp ? (
    <amp-img src={src} alt={alt} width={width} height={height} layout="responsive" />
  ) : (
    <Image src={src} alt={alt} width={width} height={height} />
  )
}

For the amp-img component, layout="responsive" means that the image will be resized based on the aspect ratio set by the weight and height, in response to the size of the viewport. The height and width figures set here don’t actually determine the size of the image that’s rendered - it’s solely used to determine the aspect ratio when layout="responsive".

Note that amp-img is a block element (vs. a standard HTML img element which is inline), so if you want to set a maximum height (or width) for your image, you’ll need to wrap your amp-img in a container, and set the max-height on that container. Alternatively, you can set display: inline-block directly on your amp-image instead. There are lots of other options, so be sure to read the official docs to see how you might best use this component for your needs.

For the NextJS Image component, the default layout is intrinsic if no value is provided. This setting scales the dimensions of the image down for smaller viewports (where the viewport is smaller than one of the dimensions of your image), but maintains the original dimensions for larger viewports. The official docs has some really nice examples for the different options you have, so be sure to check them out.

Thinking of utilising AMP components? Tell me about what components you’re using it on! I'm at https://bionicjulia.com.

Moving From React to React Native

Bionic Julia — Sat, 23 Apr 2022 00:00:00 +0000

I’ve gone full circle and have recently gone back to developing for the web in my day job with React, after working with React Native for a year. Making the mindset shift from React to React Native, and now going back to React is not hard, but can be made significantly easier if an engineer goes into a move clearly knowing what the key similarities and differences are.

With React Native still fresh in my mind, and as I’m easing back into React for web, I wanted to write this blog post, as this is what I wish I had read, before starting React Native for the first time a year ago. I wrote a blog post with my initial thoughts, way back when I first started with React Native, but this is a more fleshed out version.

But first...

For those who have a limited idea about what React or React Native is, the main thing to understand is that React for web is an abstracted “framework” that renders down to HTML, which enables it to be read by a browser. React Native is specifically used to develop native apps (the common ones being iOS and Android) and thus renders down to native mobile elements (which differs for the various platforms). This means that React for web is designed to be run in a browser environment, versus React Native which is executed in a JS runtime, from within a native application.

Whilst there’s enough common ground to enable developers to move from one to the other without too much friction, this does also mean that there are some very specific ways that React Native works, which will require a bit of a mindset shift when coming from web. I’ll start first by laying down the similarities, before covering the differences below.

Similarities

Use of the React framework

The most obvious one - whilst React Native is an abstracted framework for ultimately, mobile native platforms, it does still utilise React as a UI framework. This means that most of what you already understand around how React works, like component lifecycles, hooks and JSX transfers across.
Following on from the point above, the fact that React Native uses React means that as a developer, you’ll be writing in JavaScript (or Typescript). You likely won’t need to delve into Swift or Kotlin, unless you’re having to deal with a specific native issue, or are having to develop features that React Native doesn’t yet bridge. (Saying that, it is helpful to be able to understand these languages, especially when it comes to bug fixing and troubleshooting!)

JavaScript eco-system

The other nice thing about developing with JS, is that you get to plug into the vibrant and massive JS eco-system. Granted, you won’t be able to utilise packages that rely on browser DOMs or browser APIs, but there are still a lot of other useful packages and tools you’ll already know. This includes libraries like React Query and Redux, and also dev tools like ESLint, Prettier and Jest.
- If you’re interested, the reason this works is because React Native utilises a JS-bundler called Metro, which bundles up the application logic into a JS bundle. This is also what allows us to use fast refresh when developing at the JavaScript level.
One thing to note with testing however, is that test runners and packages generally run with Node. Your React Native app will likely include, not just JS, but also native dependencies. You’ll therefore need to mock out your native dependencies when writing your tests with these JS-based testing libraries. This can be painful to say the least, and can make writing automated and end-to-end tests difficult. Testing React Native apps can therefore be a very manual process.

Differences

Runtime environment

The main one off the bat, that a new React Native developer will notice are the primitive elements you use in your JSX. There’re no such things as <div>, <p> and <img> tags as these are HTML elements for the browser. What you’ll see instead are <View>, <Text> and <Image> elements. Note that these are then further rendered down to native specific elements for iOS and Android.
Following on from this, because we’re not running in a browser environment when using React Native, you won’t have access to browser APIs and the browser DOM. This means you won’t see event handlers like onClick or onMouseOver...which makes sense because the user will not be using a mouse when interacting with your mobile app, but instead (more likely than not), their finger. You’ll instead be dealing with onPress or onLongPress and other native gestures.
While you might miss out on browser APIs, you’ll gain by having access to mobile specific features like accelerometer, screen view modes and haptic touch. ✌️
The other big area to be aware of is how animations are programmed. With React for web, this can be done via CSS. With React Native, you’ll need to do this with the Animated API or an external package like Reanimated. Note that performance is something you want to be cognisant about when using animations in React Native, as these are determined in the JavaScript thread, but needs to be communicated to the native UI thread which can gum things up.

Styling

This was probably the most annoying one to get to grips with as it requires a shift in thinking that I wasn’t really aware of. The main thing to know is that styling on React Native does not use CSS. It instead uses a styling API which utilises something akin to inline styling, where you pass styles (via objects) directly into the individual React Native elements.
There is no cascading of styles in React Native! There’s also no such thing as selectors or nesting!
This means that on the one hand, it feels incredibly manual and archaic when you first come across styling on RN. However, once it becomes second nature, it’s actually really nice in its simplicity as you never really have to deal with weird styles appearing from seemingly nowhere, higher up in the styling cascade.
The one thing that is the same, is that both React for web and React Native uses the idea of a flexbox. The default flex-direction in React Native is column, rather than row in CSS. The default display setting in React Native is flex, so you don’t need to explicitly declare this.

Navigation

The main mental model shift is to think of “screens” in React Native, being ordered in a stack. Each new screen you navigate to means you’re adding a new screen on top of your stack. If you navigate backwards, you’re popping that screen off the stack.
The other main thing to note is the use of URLs. In a web browser, you’re able to use URLs for navigation (making a specific server call to get HTML, which in turn pulls in CSS and JS). In mobile apps however, you’re not able to use a URL to navigate to a specific screen. (You can still use URLs behind the scenes to grab resources like images on the fly though.)
URLs in the browser can also represent a navigational state within the web app (e.g. you can refresh the page and have the navigation state persist). This is not the usual behaviour in React Native apps, whereby refreshing the app will not persist navigation state by default.
React Native has third-party packages that help with navigation, with a very common one being React Navigation.

Deployment process

Not going to lie, this is the part that I like the least about React Native, or more specifically, developing for mobile. Deployment of web apps is so easy nowadays. You can literally code up an app and deploy it for the entire world to see in under 10 minutes. Not so with mobile apps.
The 2 main mobile operating systems are iOS and Android. Mobile apps for these platforms are distributed through the Apple App Store and Google Play Store respectively. You’ll therefore need to go through a review and approval process if you want to get your app listed on these stores, and these obviously will be two completely separate application processes.
You’ll also need to go through this process every time you issue a native update to your app. You can release JavaScript-only updates via the Over-The-Air mechanism (OTA), which by-passes the app stores approval processes, making it infinitely simpler. Your users will get these updates whenever they reload the app (i.e. when the JavaScript bundle is updated).
The deployment process is made more complicated if you also want to distribute a staging or beta app to app testers for QA testing before distributing to the app store. For this, you’ll likely want to use something like Firebase or AppCenter to distribute apps to a private testing group. You’ll therefore need to build different versions of your app, but also need to manage signing certificates for your iOS app to ensure this can be distributed. Fastlane is a tool that can help with managing this.

So that’s everything on my list that I can think of right now. If I’m missing anything, let me know, and I’ll add it to this list. 🙃 I'm at https://bionicjulia.com or https://instagram.com/bionicjulia

Github Actions Workflow For a React Native App

Bionic Julia — Mon, 18 Apr 2022 00:00:00 +0000

We had some downtime recently in the team, where I had just finished delivering a big feature and was in between builds. It was therefore a prime opportunity to tackle some technical debt, and one of the key things on our list was moving our Continuous Integration (CI) workflow to Github Actions.

There were various reasons we wanted to move across to GH Actions, but a big one for us was the potential to cut costs, since our repo is public and open source (which qualifies us for free GH Actions minutes). It’s also nice to be able to keep our processes tight, limiting the number of third party tools our developers have to interact with, and reducing complexity and onboarding where possible (since we already use Github as a team).

Writing CI config YAML files was not something I’ve had experience with in the past, so I volunteered to kick this off for the team. I’ll be honest - it was a pretty painful experience... but I’m really glad that I stuck with it and got our workflows working, as it’s given me a much better understanding of how our React Native app is built and deployed to our beta testers and app stores. The pain comes from having to deploy config changes and wait for the CI process to go through the various steps, only to watch it fail, so you can then make the change that you think will fix it, to then push and deploy again...wait for the CI process to restart again from scratch, only for it to fail at the next step, so you make the fix, that you then push and deploy again... etc etc. You get the point. It’s a slow and repetitive process, with a lot of trial and error (at least for me), as this was my first time doing this.

Looking at the bigger picture, I think Github Actions is a great tool and would highly recommend all developers give it a try if they already push code to Github. It’s pretty easy to get a basic workflow integrated with your git environment, and worth seeing if GH Actions can help improve your developer experience by automating certain tasks and improving your checks and processes when deploying production code.

I started with a simple workflow whereby I wanted all feature branches pushed to Github to automatically kick off the following tasks:

Linting the code;
Checking that all translations were complete; and
Running Jest tests.

Here’s what my workflow looks like.

name: Feature branch checks
#
# Branch (Ignoring) [main]
# - Build app assets
# |-- Lint project
# |-- Check i18n string
# |-- Run Tests
#

on:
  push:
    branches:
      - '**'
      - '!main'

jobs:
  setup:
    name: Setup code and environment needed for linting, translations and tests
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Cache private assets
        uses: actions/cache@v3
        id: cache-private-assets
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.CSS_ASSETS_SSH_PRIVATE_KEY }}
      - name: Install private assets if cache not present
        shell: bash
        run: .github/install_private_assets.sh
        if: steps.cache-private-assets.outputs.cache-hit != 'true'
      - name: Set up Node environment
        uses: actions/setup-node@v2
      - name: Cache node modules
        uses: actions/cache@v3
        id: cache-node-modules
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Install node modules if cache not present
        run: yarn install --immutable
        if: steps.cache-node-modules.outputs.cache-hit != 'true'

  lint:
    runs-on: ubuntu-latest
    needs: setup
    timeout-minutes: 5
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Restore private assets from cache
        uses: actions/cache@v3
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - name: Restore node modules from cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - run: mkdir -p ~/reports
      - name: Lint
        run: yarn lint:ci
      - name: Prettier
        run: yarn prettier
      - name: Upload linting report
        uses: actions/upload-artifact@v3
        with:
          name: lint-report
          path: ~/reports/eslint.xml

  i18n:
    runs-on: ubuntu-latest
    needs: setup
    timeout-minutes: 5
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Restore private assets from cache
        uses: actions/cache@v3
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - name: Restore node modules from cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Check Swedish translations
        run: yarn test:i18n 'sv-SE'

  test:
    runs-on: macos-latest
    needs: setup
    timeout-minutes: 20
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Restore private assets from cache
        uses: actions/cache@v3
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - name: Restore node modules from cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Run tests with JUnit as reporter
        run: yarn test:coverage
        env:
          JEST_JUNIT_OUTPUT_DIR: ./reports/junit/
      - name: Upload Jest JUnit test results
        uses: actions/upload-artifact@v3
        with:
          name: jest-test-results
          path: ./reports/junit/junit.xml

If you’re interested in reading more about GH Action’s workflows, check this out. To get this integrated into your Github workflow, the only thing you have to do is create a new directory in the root of your repo called .github. In this directory, create a folder called workflows and save the above file in there (calling it whatever you like). You can then go to your Github repo settings and enable Github Actions...and that’s it.

Defining when the workflow runs

This specific workflow will automatically run whenever we push a branch to Github that is NOT called main. This is set with this particular configuration:

on:
  push:
    branches:
      - '**'
      - '!main'

Defining the jobs

The workflow then goes on to say that we want to run 3 jobs simultaneously (lint, i18n and test), all 3 of which requires an initial job called setup to run. You’ll need to define an operating system runner for each of your jobs e.g. ubuntu or macOS (if you can, run your jobs on ubuntu as the minutes on Github are cheaper!). You can also define specific versions to use, but in my case, I just used the latest versions.

You can then optionally define how long the job should run for before it times out. It’s probably a good idea to include this in case something goes wrong, so you don’t end up wasting minutes on tasks which might (for instance) end up in some kind of erroneous infinite loop.

Defining the steps within a job

Going back to the setup job defined above, this does a checkout of our repo’s code, installs the necessary dependencies and caches it for subsequent jobs. In my case, we had some private assets and fonts our app needed access to as part of the build process, which in turn required SSH access to a private Github repo.

One of the nice things about GH Actions is the prebuilt actions that other community members have coded up, which more likely that not, will cover whatever you’re looking to do. Here’s the marketplace if you want to have a browse. As an example, I used this community action webfactory/ssh-agent@v0.5.4, to help me SSH with a private key, into our private repo. I then ran a custom script called install_private_assets.sh to install what I needed. I could’ve coded up the steps manually myself, but this saved me some hassle and made our workflow file easy to read and follow. Just a note here that you’ll likely want to delve into the details of a community-defined action before using it, just to verify that it’s not doing anything nefarious under the hood (like mining bitcoin!). 😝

The safer bet would be to use official actions provided by Github, where possible, which can be easily identified as their names start with actions/, e.g. actions/cache@v3 (which is an action that helps us with caching logic). Each action will come with instructions on what parameters you need to pass in to get it to work.

- name: Cache private assets
  uses: actions/cache@v3
  id: cache-private-assets
  with:
    path: |
      .private-assets
      assets/fonts
    key: private-assets
- uses: webfactory/ssh-agent@v0.5.4
  with:
    ssh-private-key: ${{ secrets.CSS_ASSETS_SSH_PRIVATE_KEY }}
- name: Install private assets if cache not present
  shell: bash
  run: .github/install_private_assets.sh
  if: steps.cache-private-assets.outputs.cache-hit != 'true'

To enable the workflow to be read intuitively from top to bottom, I named the various steps in each job with a descriptive name, using name:. In essence, the pattern for each step in a job goes like this:

Define the name of the step (optional).
Define the specific Github / community defined action you need with uses:. Alternatively, you can use run: if there’s a script command you want to run instead (e.g. yarn test:coverage kicks off our Jest tests as defined in our package.json).
Pass in the configuration or params for the action, if any, using with:

steps:
  - name: Check out Git repository
    uses: actions/checkout@v3
  - name: Restore private assets from cache
    uses: actions/cache@v3
    with:
      path: |
        .private-assets
        assets/fonts
      key: private-assets

If you need to pass in multiple arguments, use the | e.g.

path: |
  .private-assets
  assets/fonts

Workflow for building and deploying a React Native production app

If you’ve reached this point...thanks for sticking with me! As a bonus below, I’ve added another workflow I put together. This is the one that’s kicked off whenever anyone in the team deploys code to our production branch (main), which allows for a release via OTA, or a build and deploy to the Apple and Google app stores with Fastlane.

You might have noticed the reference to a secrets object in my various workflows e.g.

- uses: webfactory/ssh-agent@v0.5.4
  with:
    ssh-private-key: ${{ secrets.CSS_ASSETS_SSH_PRIVATE_KEY }}

These are essentially environment variables you can set in the Github user interface, within the Settings page of your repo. In the example below, you’ll note that ${{ secrets.CSS_ASSETS_SSH_PRIVATE_KEY }} is called from within the deploy-prod-ota job that runs in environment: production-ota. This requires that I have an environment setup in Github called production-ota, within which I can store my environment secrets. Alternatively, if you’ll be sharing secrets across environments, you can also store these secrets at a repository level.

name: Production deployment via main branch

on:
  push:
    branches:
      - 'main'

jobs:
  deploy-prod-ota:
    name: Deploy production OTA
    runs-on: macos-latest
    environment: production-ota
    timeout-minutes: 15
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Cache private assets
        uses: actions/cache@v3
        id: cache-private-assets
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.CSS_ASSETS_SSH_PRIVATE_KEY }}
      - name: Install private assets if cache not present
        shell: bash
        run: .github/install_private_assets.sh
        if: steps.cache-private-assets.outputs.cache-hit != 'true'
      - name: Cache gems
        id: cache-gems
        uses: actions/cache@v3
        with:
          path: vendor/bundle
          key: gems-${{ hashFiles('**/Gemfile.lock') }}
      - name: Install bundler if cache not present
        run: gem install bundler
        if: steps.cache-gems.outputs.cache-hit != 'true'
      - name: Install gems if cache not present
        run: |
          bundle config path vendor/bundle clean 'true'
          bundle check || bundle install
        env:
          BUNDLE_JOBS: '4'
          BUNDLE_RETRY: '3'
        if: steps.cache-gems.outputs.cache-hit != 'true'
      - name: Set up Node environment
        uses: actions/setup-node@v2
      - name: Cache node modules
        uses: actions/cache@v3
        id: cache-node-modules
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Install node modules if cache not present
        run: yarn install --immutable
        if: steps.cache-node-modules.outputs.cache-hit != 'true'
      - name: Prepare deploy environment
        run: |
          bundle update fastlane
          bundle exec fastlane update_plugins
          bash .github/make_deploy_env.sh
          yarn generate:git-hash
        env:
          RELEASE_TYPE: ${{ secrets.RELEASE_TYPE }}
      - run: echo "RELEASE_CHANNEL=$(grep EXPO_RELEASE_CHANNEL .env | cut -d '=' -f2)" >> $GITHUB_ENV
      - name: Expo OTA login
        run: npx expo-cli login -u ${{ secrets.EXPO_USERNAME }} -p ${{ secrets.EXPO_PASSWORD }}
      - name: Expo OTA publish
        run: npx expo-cli publish --non-interactive --max-workers 1 --release-channel ${{ env.RELEASE_CHANNEL }} --target bare

  #
  # Publish app to store
  # - App / Store release through AppCenter (with approval)
  # |-- Step 1: Setup production app build (approval needed)
  #   |-- Step 2a: iOS Release to app store (through AppCenter)
  #   |-- Step 2b: Android Release to play store (through AppCenter)
  #

  setup-prod-release:
    name: Setup production app build
    runs-on: macos-latest
    environment: production-build-setup
    timeout-minutes: 15
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Cache private assets
        uses: actions/cache@v3
        id: cache-private-assets
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.CSS_ASSETS_SSH_PRIVATE_KEY }}
      - name: Install private assets if cache not present
        shell: bash
        run: .github/install_private_assets.sh
        if: steps.cache-private-assets.outputs.cache-hit != 'true'
      - name: Cache gems
        id: cache-gems
        uses: actions/cache@v3
        with:
          path: vendor/bundle
          key: gems-${{ hashFiles('**/Gemfile.lock') }}
      - name: Install bundler if cache not present
        run: gem install bundler
        if: steps.cache-gems.outputs.cache-hit != 'true'
      - name: Install gems if cache not present
        run: |
          bundle config path vendor/bundle clean 'true'
          bundle check || bundle install
        env:
          BUNDLE_JOBS: '4'
          BUNDLE_RETRY: '3'
        if: steps.cache-gems.outputs.cache-hit != 'true'
      - name: Set up Node environment
        uses: actions/setup-node@v2
      - name: Cache node modules
        uses: actions/cache@v3
        id: cache-node-modules
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Install node modules if cache not present
        run: yarn install --immutable
        if: steps.cache-node-modules.outputs.cache-hit != 'true'

  prod-ios-release:
    name: Production iOS app build and release
    needs: setup-prod-release
    runs-on: macos-latest
    environment: production-release
    timeout-minutes: 30
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Restore private assets from cache
        uses: actions/cache@v3
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - name: Restore gems from cache
        uses: actions/cache@v3
        with:
          path: vendor/bundle
          key: gems-${{ hashFiles('**/Gemfile.lock') }}
      - name: Restore node modules from cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Prepare deploy environment
        run: |
          bundle update fastlane
          bundle exec fastlane update_plugins
      - uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.IOS_CERTS_SSH_PRIVATE_KEY }}
      - name: Make deploy environment
        shell: bash
        run: .github/make_deploy_env.sh
        env:
          RELEASE_TYPE: ${{ secrets.RELEASE_TYPE }}
          NAME: ${{ secrets.NAME }}
          # ... other env vars
      - run: yarn generate:git-hash
      - name: Pod clean and install
        run: |
          cd ios && pod install --clean-install
      - name: Generate fastlane certificates
        run: yarn fastlane:ios:certificates
      - name: Fastlane ios release
        run: yarn fastlane:ios:release env:$RELEASE_TYPE
        env:
          RELEASE_TYPE: ${{ secrets.RELEASE_TYPE }}
      - name: Upload build
        uses: actions/upload-artifact@v3
        with:
          name: production-ios-build
          path: ./build

  prod-android-release:
    name: Production Android app build and release
    needs: setup-prod-release
    runs-on: macos-latest
    environment: production-release
    timeout-minutes: 30
    steps:
      - name: Check out Git repository
        uses: actions/checkout@v3
      - name: Restore private assets from cache
        uses: actions/cache@v3
        with:
          path: |
            .private-assets
            assets/fonts
          key: private-assets
      - name: Restore gems from cache
        uses: actions/cache@v3
        with:
          path: vendor/bundle
          key: gems-${{ hashFiles('**/Gemfile.lock') }}
      - name: Restore node modules from cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: yarn-${{ hashFiles('yarn.lock') }}
      - name: Bundle RN Android assets
        run: npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle --assets-dest android/app/src/main/res
      - name: Clean up after bundling
        run: rm -rf ./android/app/src/main/res/drawable-* && rm -rf ./android/app/src/main/res/raw
      - name: Prepare deploy environment
        run: |
          bundle update fastlane
          bundle exec fastlane update_plugins
      - name: Make deploy environment
        shell: bash
        run: .github/make_deploy_env.sh
        env:
          RELEASE_TYPE: ${{ secrets.RELEASE_TYPE }}
          NAME: ${{ secrets.NAME }}
          # ... other env vars
      - run: yarn generate:git-hash
      - run: |
          bundle config path vendor/bundle clean 'true'
          bundle install && cat android/gradle.properties
      - name: Fastlane android release
        run: ENVFILE=.env bundle exec fastlane android release env:$RELEASE_TYPE
        env:
          RELEASE_TYPE: ${{ secrets.RELEASE_TYPE }}
      - name: Upload build
        uses: actions/upload-artifact@v3
        with:
          name: production-android-build
          path: ./android/app/build/outputs

If this helped you in anyway, I’d love to hear about it. If you have any suggestions on how I might improve this post, please do also let me know. I'm at https://bionicjulia.com, Twitter and Instagram.

Improving Lighthouse Scores For bionicjulia.com

Bionic Julia — Sat, 05 Mar 2022 00:00:00 +0000

Carrying on from my accessibility post last week, I thought I’d spend some time putting knowledge to practice. I spent my morning looking into Chrome’s Lighthouse feature and worked at improving my website to see what differences it would make to my Lighthouse scores.

Starting point

Though the main landing page of my website is bionicjulia.com, I thought I’d try to optimise bionicjulia.com/blog as this is the page that I want people to visit the most. Here are my starting scores - not too bad, but the accessibility score could definitely do with a boost.

Performance

The really nice thing about Lighthouse is the detailed suggestions it provides on how to improve your scores. If we look at the “Performance” score, it was mainly the “total blocking time” that was letting me down. Delving into it further, the diagnostics showed there were a number of long main-thread tasks being run, which was useful in identifying the worst contributors to input delay. You can read more about what causes this here.

Accessibility

I found the accessibility section to be extremely useful. There are relevant external links to help you understand more about what makes a site accessible in general, but also very specific improvement points for your site. Check out the snapshot below to see what I mean - each suggestion can be expanded to give you even more precise information on where in your code base, the problems were identified.

After the improvements were made...

I use NextJS and Vercel to serve up bionicjulia.com. Some of the suggestions on how to optimise my site was therefore out of my control, but I tried my best to improve as much as I could. Here are my post-improvement Lighthouse scores.

Not bad at all (if I may say so myself!), considering how quick and easy it was to make the fixes. I’m somewhat gutted that my performance score isn’t in the green (I need to dig deeper into NextJS if I want to improve this further), but I’m very pleased with my accessibility score improvement.

Performance

The improvement in my performance score does seem to have been led by the decrease in total blocking time and time to interactive. This was mostly achieved by reducing the size of some of my images and scripts.

Accessibility

For accessibility, I made all of the suggested changes (bar one which didn’t work for the way I had set up my website), which were mostly around:

Ensuring any links that used SVGs instead of text, had ARIA labels specifying what the link related to for screen readers.
Ensuring that my unordered lists had child <li> tags.
Improving the colour contrast ratio of my links.
Basic HTML syntax improvements.

Summary

Though I didn’t set out to optimise the main landing page at bionicjulia.com, the improvements I made also affected my index page...where I’m pleased to say I got top marks. 🎉

There’s definitely still room for improvement though, and next steps would be to run this analysis on each of the individual pages of my site. Lighthouse is also only one such tool, but it’s a good start. 🤓

If you have any suggestions on how I might improve this post, please do also let me know. I'm at https://bionicjulia.com, Twitter and Instagram.

Accessibility Tips For Web Development

Bionic Julia — Fri, 25 Feb 2022 00:00:00 +0000

One of my knowledge gaps within web development that I really want to bridge is accessibility. In all of the apps / engineering teams I’ve worked on professionally to date, accessibility (unfortunately) has never played a front and centre stage, and tends to be more of an afterthought. This is mostly due to time and resource constraints, but also a lack of knowledge on how to implement accessible apps and the benefits it brings.

To start making steps to improve my knowledge, I recently decided to take an online course on accessibility for web development. Here are my quick notes and key takeaways, written in a cheat sheet format (mostly for me to reference back to at a later date!). If you’re knowledgeable about accessible web development, and think I’ve missed something crucial out, please do let me know, and I’ll add it to the list.

Screen readers

Add alt text to images, otherwise screen readers will end up reading the filename.
Empty strings as alt tags will cause the screen reader to skip over the image (which may be the desired effect you want, e.g. for user uploaded images or decorative images).
For complex images, you could make the image hidden to screen readers, but add some text below, that’s visually hidden, but readable by screen readers.
If you have a video, add captions. At WCAG2 Level A, you can include this as a transcript. To improve on this, use synchronised captions.
Screen readers ignore CSS background images.

💡 In Mac OS, the screen reader can be activated via the VoiceOver settings.

Accessible HTML

Use appropriate semantic markup. Some have no special functionality, but others do, like button, input and textarea.
- e.g. if you just use div, this would not be read by a screen reader.
Don’t choose which header tags to use based on formatting! e.g. there should only be one h1 tag per page.
Ensure that the reading and navigation order (determined by code order) is logical (so it makes sense when read by a screen reader from top to bottom).
Use form field labels, so that form inputs can be read by screen readers. Labels can be used explicitly (use for to link it to a particular input name) or implicitly (wraps the name and input field - does not need for attribute).
The label tag only works with certain elements (e.g. input, button).
- If you need to label an element that’s not “label-able”, use aria-label attribute instead (however note that it would only work on focusable elements, so would also require a tabindex attribute).
Use a specific class to visually hide an element that’s solely for screen reader only content.

  .visuallyhidden {
    position: absolute;
    left: 0;
    top: -500px;
    width: 1px;
    height: 1px;
    overflow: hidden;
  }

If you choose not to use the button element, and instead to use a div styled as a button, you’d also need to include the following attributes to make it accessible:
- onclick=”xxx”
- role=”button” (this is the ARIA role, used by screen readers)
- tabindex=”0” (or whatever number, to make it tab-able and focusable with the keyboard)
- onkeyup=”xxx” (to ensure keyboard-only users can interact with the button)

ARIA - Accessible Rich Internet Applications

Labels
- aria-label - inline attribute
- aria-labelledby - allows you to link to an element id that contains the text for the label e.g. could be handy for handling translations
- aria-describedby - provides extended information the user might need
Roles can be applied to any element. Role examples include button, checkbox, tree, banner.
States and properties inform what the current state of an element / app is in e.g. is a checkbox checked, or is a form invalid? These would need to be added and removed in line with the user action.
You can use ARIA properties within CSS since they are just data selectors.
The ARIA spec allows us to mark an element as containing live data so that screen readers can read out live updates as they come.
- assertive means interrupt, polite announces the update when the screen reader is next idle. off will not read the update.
- This kicks in whenever the content between the div tag changes.

  <div aria-live="assertive">Waiting for a ride</div>

Focus management

Keyboard shortcuts - allow users to access different features through using the keyboard alone.
Keyboard only users - show focus rings around elements which are also safe for screen readers. Should be able to reach the next focusable element by tabbing.
- Also should not result in a substantial change in the page layout e.g. page shifts because of the focus ring designs.
Skip links help users skip over large headers and navigation, to go straight to the main content of the site (without having to tab through each link).
- Create an anchor within the body and add it to the start of your HTML content. Make it visually hidden, until someone hits tab (and make it immediately in focus).
- The anchor should then link to the main content.
Accessible tab navigation allows a user to navigate to the next tabbable item. Shift + tab allows a user to navigate back.
- Tabbable elements out of the box include: a, button, input, select, textarea, iframe
Use a tabindex attribute to make any element tabbable
- A negative value means it should be focusable, but not reachable via sequential keyboard navigation.
- 0 means the element should be focusable and reachable, but its relative order is defined by the platform convention.
- A positive value means it should be focusable and reachable. Its relative order is defined by the value of the attribute. The higher the value, the earlier it’s reached.
Note, top level elements should be tabbable, but child elements should be arrow-key reachable e.g. if you have a tab navigation, with “more” as one of the tabs, the child links within “more” should not be accessed via the tab key, but arrow keys.
You can get the DOM’s current active element by using document.activeElement. This is useful to store the currently focused element before a page transition so you can return the user to it later.
Tab trapping is a JS technique where you grab the first and last element in a modal, and listen to keydown events for when the user is on the first/last element. You can then ensure that the tab and shift+tab takes the user through a loop of the tabbable elements in the modal (otherwise the user might tab out of the modal to the main document, even whilst the modal is open).

Visual considerations

Use this website to check colour contrast: https://webaim.org/resources/contrastchecker/
- Lighthouse audit (Chrome extension) can also check your live site.
- Chrome devtools’s colour picker shows the contrast ratio of two colours, however, this only works if you’ve set the child within a parent component (rather than against the document body).
You shouldn’t just rely on colour to relay feedback back to the user (e.g. with form validation). There should also be some other method of feedback, like text.
Consider using NoCoffee for Firefox to simulate what visual impairment views might look like.
Consider keeping related items (especially those that provide feedback to user interactions) close together to help users with limited field of vision.
Set the lang attribute (the language of your site) at the top of your HTML file (and any subsequent sections where the language deviates from the default).
Even though it might not be visually apparent, WCAG also specifies you should ensure your HTML is free of syntax and parsing errors.
Users can set a “prefers reduced motion” option on their operating system. This is important for users who may suffer from seizures.
- This is accessible within CSS via an @media (prefers-reduced-motion) query.
Users can also set their system’s preferred colour scheme (i.e. light vs dark colour scheme).
- This is accessible within CSS via an @media (prefers-color-scheme) query.

Tooling

Use an IDE linter on your code base e.g. eslint-plugin-a11y
Use an accessible design system, e.g. from Adobe React Spectrum, Bootstrap, Google’s Material Design
Developer tools from Deque: https://www.deque.com/axe/devtools/
Lighthouse: https://developers.google.com/web/tools/lighthouse

Creating a Sentry Logging Module to Set Context in a React Native App

Bionic Julia — Sat, 19 Feb 2022 00:00:00 +0000

We experienced a real puzzler of a bug last week. We had just released a massive new feature, and over the next two days, had gotten a number of users emailing in saying they couldn’t proceed at a certain point of the flow (a button that should have been pressable remained disabled). Looking at the analytics, the data agreed with what the emailers were saying, and the numbers experiencing the issue were not insignificant.

Unfortunately, when we set about to solve the issue, no one in our engineering team, or the wider team could replicate the bug. Reading through the code didn’t surface any obvious errors either, and we were stumped. So what’s one to do next? 🤔

Get more information.

Our app’s logging capabilities up until this point had been woeful. We were tracking app errors with Sentry but nothing much else besides that. This meant that we were not able to surface any information to do with our bug above, as the app was not crashing per se. I therefore created a custom logging module to allow us to raise custom errors in Sentry, wherever we needed to understand the context around why users might be experiencing certain issues (rather than just relying on Sentry’s automatic error tracking when the app crashes).

Here’s what my logging module looks like. Note that it uses the concept of Sentry’s custom scope and context which you can read more about here. I found the official documents a little confusing, and it took a couple of tries before I started to see my custom logs show up, so I thought I’d write this up for others who might also be struggling.

Logging module

import * as Sentry from '@sentry/browser'

enum EFeature1Context {
  EXAMPLE_CONTEXT_1 = 'EXAMPLE_CONTEXT_1',
  EXAMPLE_CONTEXT_2 = 'EXAMPLE_CONTEXT_2',
}

enum EFeature2Context {
  EXAMPLE_CONTEXT_3 = 'EXAMPLE_CONTEXT_3',
}

export const contextNames = {
  ...EFeature1Context,
  ...EFeature2Context,
}

export type TContextName = keyof typeof contextNames
export type TFeatureName = 'feature_1' | 'feature_2'

export const logLevel = Sentry.Severity

export function log(
  featureName: TFeatureName,
  errorMessage: string,
  contextName: TContextName,
  properties: object,
  level: Sentry.Severity = Sentry.Severity.Error,
) {
  Sentry.setContext(contextName, properties)

  Sentry.withScope((scope) => {
    scope.setTag('feature', featureName)
    scope.setLevel(level)
    Sentry.captureException(new Error(errorMessage))
  })
}

export default {
  log,
}

The route I went down was to create a log method, that takes a number of arguments, which are passed into Sentry’s setContext and withScope methods. The idea is to first set up the Sentry context which includes an object which you can stuff with whatever information you need for debugging. I then created a custom scope to set a tag (making it easily searchable within Sentry), the error level (e.g. info, warning, error, critical etc. which you can get from the Sentry.Severity list that comes inbuilt with the Sentry package) and the error message.

Note that the separation of context names into different enums is for convenience and helping to keep track of the various contexts you might be setting if your app is a large one, and you’re using Typescript.

To use the Logging module in your app, you’d just need to add this line of code wherever you want to log additional context.

Logging.log(
  'feature_1',
  'example_error_message',
  contextNames.EXAMPLE_CONTEXT_1,
  {
    user_type: 'abc',
    country: 'uk',
    screen: 'screen_name_example',
  },
  logLevel.Error,
)

Setting Up React Native Jest Tests With Higher Order Components

Bionic Julia — Sat, 12 Feb 2022 00:00:00 +0000

If your React Native app is anything like our app, you’ve got wrappers upon wrappers, wrapping your screens and screen components. Some examples might be:

SafeAreaProvider - to ensure you’re only accessing a device’s safe area
ThemeProvider - say you were using something like Styled Components to provide a theme context to your entire app
Redux - to manage state across your app

This can make things tricky when it comes to writing your unit and integration tests, as your components might inadvertently depend on something that’s being provided by one or more of your higher order components (HoCs).

In an attempt to simplify the setup of our Jest tests, we wrote some helper functions to make it easier to tap into the HoCs we needed on a test by test basis. Making things simpler means lowering the barrier to writing more tests whilst shortening development time, so this is a major win. 🎉

Here’s an example of how it can be done in Typescript. The external packages we use are Redux Toolkit, Styled Components and React Native Safe Area Context.

// testHelpers.tsx

import * as React from 'react'
import { getDefaultMiddleware } from '@reduxjs/toolkit'
import lodash from 'lodash'
import { SafeAreaProvider } from 'react-native-safe-area-context'
import { Provider as ReduxProvider } from 'react-redux'
import renderer, { ReactTestInstance } from 'react-test-renderer'
import createMockStore from 'redux-mock-store'
import { ThemeProvider } from 'styled-components/native'

import { TRootState } from '@app/core/state/root'
import { initialState } from '@app/core/state/mockedInitialState'
import { theme } from '@app/themes'

type DeepPartial<T> = {
  [P in keyof T]?: DeepPartial<T[P]>
}

type TConfig = {
  mockRedux?: boolean
  mockSafeAreaProvider?: boolean
  mockTheme?: boolean
  state?: DeepPartial<TRootState>
}

const initialMetrics = {
  frame: { height: 0, width: 0, x: 0, y: 0 },
  insets: { bottom: 0, left: 0, right: 0, top: 0 },
}

export function createMockedElement(element: React.ReactElement, config?: TConfig) {
  let mockedElement = element

  if (config?.mockRedux !== false) {
    const middlewares = getDefaultMiddleware()
    const mockStore = createMockStore(middlewares)
    const state = lodash.merge(initialState, config?.state)
    const store = mockStore(state)
    mockedElement = <ReduxProvider store={store}>{mockedElement}</ReduxProvider>
  }

  if (config?.mockTheme !== false) {
    mockedElement = <ThemeProvider theme={theme}>{mockedElement}</ThemeProvider>
  }

  if (config?.mockSafeAreaProvider !== false) {
    mockedElement = <SafeAreaProvider initialMetrics={initialMetrics}>{mockedElement}</SafeAreaProvider>
  }

  return mockedElement
}

export function createReactTestInstance(element: React.ReactElement, config?: TConfig): ReactTestInstance {
  return renderer.create(createMockedElement(element, config)).root
}

There’s quite a lot going on here, so let’s break it down. But first, we should talk about...

How the helper functions will be used in practice

I always find it easier to first understand how we’d want to use these helper methods in the wild. I’ve therefore added an example of how we’d integrate these helpers into our tests. Note that this uses React’s Test Renderer which is useful for say, checking for the presence of expected elements.

import { createReactTestInstance } from './testHelpers'

describe('MyComponent tests', () => {
  it('renders correct version for users who shown interest', () => {
    const instance = createReactTestInstance(<MyComponent />)

    expect(instance.findByProps({ testID: `interested-icon` })).toBeTruthy()
  })

  it('renders correct version for users who have not shown interest', () => {
    const instance = createReactTestInstance(<MyComponent />)

    expect(instance.findByProps({ testID: `not-interested-icon` })).toBeTruthy()
  })
})

If you wanted to test for whether certain user actions result in specific expectations, the React Testing Library (which sits on top of React’s Test Renderer) is great for that. Rather than using our createReactTestInstance helper, we can just tap into the createMockedElement helper. Here’s an example.

import { fireEvent, render } from '@testing-library/react-native'
import { act } from 'react-test-renderer'

import { createMockedElement } from './testHelpers'

const navigateMock = jest
  .mock
  // your mock...
  ()

describe('BackButton tests', () => {
  it('navigates to the right screen onPress', async () => {
    const mockedElement = createMockedElement(<BackButton previousScreen="PreviousScreenName" />)

    const renderAPI = await render(mockedElement)

    await act(async () => {
      const backButton = renderAPI.getByTestId('button-back-navigation')
      await fireEvent.press(backButton)
      expect(navigateMock).toHaveBeenCalledWith('PreviousScreenName')
    })
  })
})

Now that you understand how the helper functions are going to be used in practice, let’s go back to how we set up the helpers file.

Breaking how the helpers file

At the heart of this file is the createMockedElement function.

export function createMockedElement(element: React.ReactElement, config?: TConfig) {
  let mockedElement = element

  if (config?.mockRedux !== false) {
    const middlewares = getDefaultMiddleware()
    const mockStore = createMockStore(middlewares)
    const state = lodash.merge(initialState, config?.state)
    const store = mockStore(state)
    mockedElement = <ReduxProvider store={store}>{mockedElement}</ReduxProvider>
  }

  if (config?.mockTheme !== false) {
    mockedElement = <ThemeProvider theme={theme}>{mockedElement}</ThemeProvider>
  }

  if (config?.mockSafeAreaProvider !== false) {
    mockedElement = <SafeAreaProvider initialMetrics={initialMetrics}>{mockedElement}</SafeAreaProvider>
  }

  return mockedElement
}

This function takes two arguments - the element/component you want to test, and an optional config object. This config object allows you to specify what wrappers to include when rendering your component during the test (if any). For example, if you need to mock the Redux state, you can set up your test in this way:

it("doesn't open the modal when row is active", async () => {
  const mockedState = { show_modal: false }
  const config = { state: mockedState }

  const mockedElement = createMockedElement(<Row />, config)

  const renderAPI = await render(mockedElement)

  await act(async () => {
    // ... your test expectations
  })
})

You can similarly do the same if you need to include the ThemeProvider and / or SafeAreaProvider wrappers. As defined in TConfig, note that these two options take boolean inputs.

Deeper dive into setting up Redux state

When mocking the Redux state, you’ll likely need to ensure your test Redux state has been set up with some initial values. To do this, we extracted all the initial states out from our various Redux Toolkit slices and combined it into a single object, which we then passed into the lodash merge function (to ensure it deep merges with our mocked state).

// @app/core/state/mockedInitialState

import { initialStateFeature1 } from '@covid/core/state/feature1.slice'
import { initialStateFeature2 } from '@covid/core/state/feature2.slice'
import { initialStateFeature3 } from '@covid/core/state/feature3.slice'

export const initialState: TRootState = {
  feature1: initialStateFeature1,
  feature2: initialStateFeature2,
  feature3: initialStateFeature3,
}

And that’s it! Hopefully this makes your React Native testing life a little easier. 😄 If you’ve got any suggestions or improvements for me, do let me know - I’m always keen to up my testing game! I'm at https://bionicjulia.com, Twitter and Instagram.

React Formik and Yup Troubleshooting Tips

Bionic Julia — Sat, 29 Jan 2022 00:00:00 +0000

I’ve been spending the last couple of weeks reworking how we render forms in our React Native app. The main driver for this is a new feature we’re releasing soon, that requires over 150 questions to be asked to the user. In order to minimise code duplication and to make the editing of form questions easier going forward, we decided to go down the route of programmatically rendering the various forms and their questions from a large JSON file.

Rendering our forms this way also meant having to programmatically generate the required Yup validation object. As we’re going to be migrating users across from an older system, there’s also an element of certain forms having pre-filled existing data that needs validating.

So far, it all seems to be working out great, but there were some issues I can across during the build that I thought I’d note down. This is mostly for my future self as I’m sure I had come across some of these same issues in the past but had forgotten about them...so here’s to saving my future self some time. 😃

Issue: If your form is pre-populated with data and validation doesn’t work on component mount

Ensure you’ve set validateOnMount={true} within your Formik component props. Also, check that you haven’t included formikProps.dirty as an additional check to enable your submit button (which I may or may not have done, then wasted 30 minutes trying to figure out why my button continued to remain disabled). 😅

<Formik
  validateOnMount={true}
  initialValues={initialValues}
  onSubmit={onSubmit}
  validationSchema={validationSchema}
  ...
>
 {(formikProps) => {
  return (
    <Form...

Issue: Not all field validations are working as expected

Check that you’ve initialised each field value to at least an empty string, otherwise Yup will not know that the field(s) exists and will not be able to validate it.
For context, I had some conditional fields that were only required if certain criteria were met. These fields were being ignored, because they were not initialised when the form component was mounted.

Issue: How to access `formikProps` outside the form component

There are a few ways of doing this depending on what specifically you’re trying to achieve.

If you need to access formikProps within a child component of the form, you can either pass it down as a prop, or use the useFormikContext() hook.
If you need to access formikProps at the form component level, but outside the render method, create a React ref and use the innerRef Formik property to reference your form (and access the Formik methods).

export const MyForm = () => {

  const formRef = useRef(null);

  const handleSubmit = () => {
    if (formRef.current) {
      formRef.current.handleSubmit()
    }
  }

  return (
    <Formik
      validateOnMount={true}
      innerRef={formRef}
      initialValues={initialValues}
      onSubmit={onSubmit}
      validationSchema={validationSchema}
      ...
    >
    // ...
  )
}

Issue: Using React lifecycle hooks that are dependent on `formikProps`

For context, the issue I was faced with was how to check when a user had filled in specific form fields and moved on to the next question (for animation purposes). A solution I came up with was to utilise the useEffect hook to check if my requirement passed, whenever the formikProps.values array had been updated.

I was using ES6 arrow function syntax, and was getting an error when I tried to do this:

<Formik
  ...
>
  {(formikProps) => {

    React.useEffect(() => {
      updateQuestionsState(formikProps);
    });

    return (
      <Form...

    )
  }}
</Formik>

To fix the error, I subbed out the arrow function with a named function:

<Formik
  ...
>
  {function FormWithUseEffect(formikProps) {

    React.useEffect(() => {
      updateQuestionsState(formikProps);
    });

    return (
      <Form ...

    )
  }}
</Formik>

If you have any suggestions on how I might improve this post, please do also let me know. I'm at https://bionicjulia.com, Twitter and Instagram.

A Guide For New Programmers (Part 3)

Bionic Julia — Sat, 22 Jan 2022 00:00:00 +0000

This is the final part in a 3 part series, so if you haven’t already done so, be sure to first check out how I got started with programming (part 1) and how I learn new things (part 2).

The aim of this blog post is to provide some guidance on questions to ask yourself if you’re starting from scratch. This is the #1 topic most people tend to send me questions on, but is one that I also cannot provide a succinct response to, because it’ll differ for everyone. This post is my attempt to provide an answer in a more helpful way.

What I’d do if I was starting out today

If I were to start again from scratch today, here are the list of questions I’d be asking myself to get a sense of the direction I need to take. In order:

Why do I want to learn programming?
What goal do I want to accomplish as a first step?
What areas of tech / programming am I most interested in?
What are the skills within this area that will best enable me to get to where I want to go?
How should I prioritise the learning of these skills?

Once you’ve answered question 5, you should have a list things you want to learn and what to learn first. This is where part 2 of this blog post series kicks in. 😀 As the questions above might seem a little abstract, I’ll walk through each one giving some examples along the way to help illustrate my thoughts.

Question 1: Why do I want to learn programming?

The world of tech and programming is absolutely massive, with an infinite number of things you could learn. Being able to articulate why you want to learn programming will go a long way to giving you direction and helping you filter out a lot of what you think you might want to learn.

The other thing to note is that learning programming is a long road, and it can be difficult and frustrating at times. You’ll need to be motivated by something to ensure you keep going. Knowing why you really want to do this can be a good driving force for when times get tough. The deeper you’ve thought about the why, the stronger its hold will be on you - this is something you really want to connect to on a deep, emotional level.

Some examples might be:

I want to make a career change from finance to tech because....[fill in the blank].
I want a job that allows me to work remotely and with flexible hours, so I can spend more time with my family.
I would like to increase my efficiency at work so I can spend my time learning new skills that will enable me to get promoted and increase my impact at work.
I would like to publish a game on Steam and earn recurring revenue, so I don’t have to continue working 2 jobs.

Question 2: What goal do I want to get to as a first step?

Once you know your “why” (i.e. the direction you want to go), the next thing to determine is where you want to get to as a first concrete step (your first milestone on your journey). If your why was, “I want to make a career change from finance to wellness-tech”, your goal might be, “To get a job at Peloton”.

The main reason I think it’s important to clarify what your first goal is, is so that you can learn with a concrete purpose in mind. It will help you focus specifically on solving the problem at hand, rather than learning for learning’s sake.

Tips:

To make your goal stronger, add a timeframe and make it as specific as you can e.g. “To get a job at Peloton within the next 12 months, working on technology a user interfaces with on a daily basis”.
To make your goal more achievable, set yourself up for success and think about what the smallest possible realistic representation of that milestone might be. i.e. don’t try to do too many things at once. Make it small, concrete and measurable so that you know when you’ve achieved that goal.

Other examples:

Why: Increasing efficiency at work. Goal: Learn how to automate the transfer of data from CSV to company database, freeing up 4 hours in my working week.
Why: Publish a game on Steam. Goal: Get a minimum viable game working on my computer by Christmas, with a single level, allowing players to collect coins.

Question 3: What areas of tech / programming am I most interested in?

The answer to this question might already be obvious to you from the answers you came up with in questions 1 and 2, but if not, I’d really encourage you to have a think about what areas of tech and programming really excites you.

Some of the main areas you might want to consider here are:

Backend development - working with databases, servers and designing APIs.
Frontend development - working with user interfaces and experiences.
Systems engineering and reliability - overseeing the entire system and ensuring all parts are working seamlessly together.
Games development - designing and developing games.
Hardware development - working on the interfaces between electronics and mechanical system elements.

Whilst you can, of course, decide you want to go after more than one area, like full-stack development (both backend and frontend), I’d really encourage you to choose one area to lead with as a first step. The main reason for this is focus, especially in the early days when you’re learning everything from scratch and there is a lot to learn.

Side note: If you are interested in full-stack development, my humble opinion is to first start learning backend development and understanding data transfer between databases through to APIs to be consumed by the frontend. It feels easier to then continue with learning frontend development. I’m possibly biased because that was the path I took. 😝

Once you’ve identified the area you want to start with, revisit question 2 to see if there’s anything you’d change in your answer to make it more precise / clearer. It’s an iterative process, with the goal being to determine the smallest next step you can take, that still remains a meaningful goal to you.

Question 4: What are the skills within this area that will best enable me to get to where I want to go?

The answer to this question will really depend on what you answered for question 2. It will also be clearer, the more precise and detailed your answer to question 2 is. If you’re having trouble answering this question, go back to question 2 and have a deeper think about how to define a smaller goal. 🙃

Some examples:

Goal: get a development role at Peloton. Area: frontend development.
- At this point, do some research to find out what Peloton’s tech stack is. You might find out they use React + NextJS on their website, and React Native for their mobile app. This might be sufficient for you, but you might also want to go back and revisit your goal to be more focused.
- Revised goal: get a frontend development role at Peloton, working on their mobile app. Area: frontend mobile development. Skills: React Native.
Goal: learn how to automate the transfer of data from CSV to company database. Area: backend development.
- Let’s say your company uses Postgres for its database. One of the necessary skills would be SQL. You’d then have to do some research to figure out how you might be able to transfer CSV data to SQL commands. From your research, you might learn that you can use Python or Ruby. You then need to make a choice at this point, perhaps taking considerations like what backend languages your company uses, or what the most popular language used in industry is today, into account.
- From here, you might say the skills you need are Python and SQL.

Question 5: How should I prioritise the learning of these skills?

If you’ve managed to nail it down to one skill - well done! Check out my second post in this series if you need some guidance on how to learn something new. If you’ve landed on more than one skill to learn, you can either: (i) try to be more precise in your goal / area and therefore skills needed, or (ii) just roll with it, because honestly, it might just be necessary.

If this is the case, my suggestion would be to prioritise the skill you find most interesting or easiest in the first instance. What you want in the early days are quick wins, to prove to yourself that you can do this and that you’re progressing in tangible ways. This will give you the motivation to continue learning and pushing the boundaries of your knowledge.

As you make progress in the first skill, you might then choose to commence learning the second skill in parallel. I’m a strong proponent of learning with the aim of solving your problem, so going back to the example above, the aim here isn’t to learn everything about Python, and then everything about SQL - it’s about learning enough Python to understand how to manipulate CSV data, then learning enough SQL to save that data to a Postgres database.

Conclusion

As I’ve mentioned in my previous posts, this is just my thought process and opinion on how to go about learning programming. If this helped you in anyway, I’d love to hear about it. If you have any suggestions on how I might improve this post, please do also let me know. I'm at https://bionicjulia.com, Twitter and Instagram.

And finally, good luck! You’ve got this! 💪🏻😃

A Guide For New Programmers (Part 2)

Bionic Julia — Sat, 15 Jan 2022 00:00:00 +0000

First things first, if you haven’t already done so, be sure to read my first post in this series for a little more context.

Otherwise, jumping straight in where I left off...

How I learn new things and continue to develop my programming skills

Back to the bootcamp

One of the first things that was drummed into us from Day 1 of the coding bootcamp was that it’s not really the language or framework you’re learning that’s important. It’s much more about meta-learning i.e. learning about learning, and more specifically, learning how you learn.

I can’t say it clicked immediately. When I first started, I was learning all sorts of new things I’d never come across before - command line, git, Ruby, Ruby on Rails, APIs, for loops, switch statements, MVCs etc. and it just seemed like there was an overwhelming number of things to learn, for say just Ruby alone! Forget about learning how to learn, I just needed to buckle down and learn about Ruby!

And whilst yes, there is an element of having to do that in the early days, I soon reached a point where I realised:

I was never going to be able to memorise all of these things;
Programming languages and frameworks follow certain patterns; and
There’s this thing called Google and the Internet which helps you find the answers and things you might need.

Why meta-learning is so useful

To give you a concrete example, I started by learning Ruby as my introductory programming language. You learn about:

Types like strings, integers and booleans;
Data structures like arrays and objects; and
Data flow using if statements and loops (amongst, of course, a whole host of other things).

I spent a lot of the early days perusing the Ruby documentation, learning about how you manipulate data with the various methods and notation. This was 100% time well-spent as it taught me a lot about the lower level workings of the language, which is useful as a beginner. However, in the years since, I’ve stopped programming in Ruby and now use Python and JavaScript as my day-to-day programming languages... so what’s one to do? Read through all the Python docs and JavaScript docs? Take another bootcamp for those languages?

Well maybe yes, if your role requires you to learn a particular language for its very specific features, but I’d guess that for most people this isn’t the case. When I first had to code in JavaScript and Python, guess what? They’ve both got concepts of types, data structures and data flow as flow. When I sat down to work on my first Python repo then, rather than having to spend days reading Python docs and practicing methods, it was really more about recognising core programming and software development concepts, figuring out the initial questions to ask, and then using the internet to find relevant resources and iteratively improve on the phrasing of those questions to get me closer to the potential answers I needed.

It’s similar with frameworks by the way. I started with Ruby on Rails, where I learnt about concepts like Model-View-Controller (MVC), relational databases (Postgres) & ORMs, and how routing works. Since working with Python, I’ve had to learn FastAPI and Django. And this was all for a new job I accepted, which meant I didn’t have the luxury of taking my own sweet time to learn them - I had to figure out how to get up to speed ASAP (and not least because I had a probation period to pass lol). 🙈

People learn best in different ways, so once again, the only thing I can do here is communicate what I did (and continue to do), to learn quickly and level up. One quick aside before I start - you can of course, choose to stick with the same programming language / framework and gain expertise in one thing. Just always be aware that technology and how we develop software moves extremely quickly, with languages going in and out of fashion, and different problems requiring different languages to solve them. I’d also say that the meta-learning skill can be applied to other areas in your life, where you might be trying to learn something new. e.g. I’m teaching myself how to play the drums and it’s been brilliant.

Julia’s method

Here are the steps I tend to go through whenever I want to learn something new. To help communicate what might be fairly abstract ideas, I’ll use two examples: (i) learning a new framework like React; and (ii) learning how to play the drums.

Step 1: Figure out the core concepts that underpin the foundations of what you’re trying to learn

This step is essentially about trying to get a list of the fundamental concepts that underpin what you’re trying to learn, as quickly as possible. What’s the minimum set of ideas / core concepts you need to understand, to be able to deliver something that works? Filtering out the unnecessary allows you to focus on what will help you make the most progress in the shortest amount of time. Making progress quickly keeps you motivated to keep learning.

Resources I tend to use for this step
- Short YouTube videos to get a quick demo / lay of the land.
- “Experts” who’ve been there and done that, like senior developers and industry influencers - ideally someone you know and trust.
- Paid coaching - can be expensive, but potentially saves a lot of time as you don’t then have to filter out bad information yourself.
Examples
- React: understanding component lifecycles and props vs. state, so I can get a parent and child component rendering on screen with dynamic information. 👩‍👦
- Drumming: learning how to count beats and get basic limb independence for the snare drum, hi-hat and bass pedal, so I can play an 8-bar beat for a classic rock song. 🎶

Step 2: Practice those concepts in “real world” scenarios

Once you’ve identified what you need to learn in the first instance, begin actively practicing them. You can start by reading about it or watching videos, but try to move on to actual “doing” as quickly as possible, as it forces you to think about how to do something, which in turn aids with better retention.

What I also try to do is practice in different environments, with each progression getting me closer to a “real world” application. Why? Because real world problems force you to think more realistically about what you’re trying to do, and what you need to learn next to get there. i.e. it guides you to learn with context (which I’ve found to be so much more effective, vs. learning from set examples). Sandbox problems are great to start, but you’ll reach a plateau in your learning if you stay there.

Playing around in different environments also gives you the chance to apply your knowledge in different contexts, which helps build your mental model of how something works. It’s also immensely satisfying to be building something that solves a real problem, as opposed to just working on something for the sake of it. 🙂

Potential resources
- If you’re learning a new programming language, HackerRank / CodeWars / LeetCode.
- Reading through your company’s code repo and working on tickets (can be intimidating, but it’s effective).
- Similarly, find relevant open source repos, read through the code, and contribute what you can.
- YouTube videos for finding ideas of what you can build and walking you through the steps (but do this actively, rather than just sitting back and watching).
Examples
- React: the usual - build your own To-do app or a weather app. 😉
- Drumming: pick a song you want to play, and start jamming. 🤘🏻

Step 3: Structured learning

If you’ve been learning in real-world environments, you’ll soon begin to realise how much there is that you still know nothing about. It’s really easy to start losing hope at this stage, but don’t! Take heart - this is a great sign of progress because it shows you’ve been pushing your boundaries and dealing with real world complexity, which is, of course, not going to be easy.

The important thing to note here is how to structure your learning so you don’t get bogged down in trying to pursue too many things or the wrong things. This starts with developing the skill of asking the right questions, because once you know what those are, it’s generally pretty easy to find the answers by using Google or YouTube search. It will be an iterative process, which gets easier over time, the more your mental model builds.

What I’ll tend to do is the following:

Come across an issue to solve. Keep Googling until I find potential solutions that solves the one issue I’m trying to solve.
Along the way, I’ll make a note of topics I come across, which I don’t know / understand, and that I want to do further reading on. However, I won’t spend a lot of time on those yet, as it’s easy to get bogged down, without even knowing how crucial it is to know those things at this stage.
I’ll continue just Googling and learning only the things necessary to solve my immediate problem. Each new puzzle solved adds to my mental model of how I think [React / drumming / whatever] works. After a while, when I feel like there’s too much on my “to learn” list, or if I’m finding it hard to piece together new information to add to my mental model, I’ll look at finding a learning resource that deep dives on the topic, in an organised way.
I’ll try to choosing a resource that’s active, rather than passive, because once again, it really helps things stick if you’re actively working through an issue. What I’ll generally find at this point is that I’ll be able to speed through materials, as there’ll be a lot that likely just serves to confirm (or correct) your mental model of how something works. At other points, you’ll hopefully get “a-ha” moments that allows groups of ideas you were struggling with to unlock and make sense.
Potential resources
- Paid learning platforms like Udemy and Skillshare.
- Free learning platforms like freeCodeCamp and Coursera.
- Courses from industry experts from platforms like Frontend Masters.
- Books on a subject matter.
Examples
- React: Kent C. Dodds Epic React course ⚛️
- Drumming: Going through the Drumeo Method course 🥢

Step 4: Continuous learning

By this point, you should have gotten a good understanding for the new skill you’re trying to learn. You’ll also have realised there’s still a seemingly infinite number of things that you don’t know...so the learning doesn’t stop.

This step should actually underpin all of the previous steps, as I’ve found that it helps keep my learning current and relevant, along with giving me new ideas and resources that helps further propel my learning. It’s all about consuming materials to diversify my sources and serves as unstructured learning, to fit around what I might be doing in the previous steps e.g. whilst I’m bored, going for a jog or commuting.

Here’s an ordered list of the resources I tend to use (from most to least used)

Podcasts
Books
Newsletters
Blog subscriptions
YouTube channels

Examples:

React: JS Party podcast, The Opinionated Guide To React book, React Status newsletter 📕
Drumming: Kristina Schiano YouTube, Drumeo 🥁

Miscellaneous tips

Take breaks when you’re not actively thinking about what you’re trying to learn and allow your brain to go into diffuse thinking mode. Ideally do something physically active, move your body and get a sweat on.
Get adequate, good quality sleep.
Stay hydrated.

Phew, that was a long post! Once again, this is just my method, and what I’ve found works well for me. If you’ve got any suggestions, or have found specific methods that work for you, I’d love to hear from you. Also, if you have any feedback on how I might make my post clearer, give me a shout. I'm at https://bionicjulia.com, Twitter and Instagram.

A Guide For New Programmers (Part 1)

Bionic Julia — Sun, 09 Jan 2022 00:00:00 +0000

One of the most frequently asked questions I get is where to start as a beginner wanting to learn programming. This question is so broad and so personal that I cannot really give an answer that will be true for everyone. What I can do though, is to give you my perspective and story on how I started out, what I do to continue learning and up-skilling, and finally, with the benefit of hindsight and experience, how I would think about making the decision of where to begin today.

As there’s quite a lot to write about, I’ll break this topic down into a number of sections:

How I got started with programming;
How I learn new things; and finally
What I’d do if I was starting out today.

How I Got Started With Programming

Back to the 90s

It was back in the 90s, when we got our first family computer and dial-up internet at home, when I first started programming. It was pretty much just building personal websites using sites like Geocities, Blogger and LiveJournal, which is where I was first introduced to HTML and CSS. Things were relatively basic and simple then (I hadn’t come across Javascript), and I would spend hours making things like review sites and logging books read... but also connecting with other hobbyist tinkerers doing similar things and learning from them.

The funny / sad thing to note, is that the vast majority of those online “friends” were female, so it would have been a realistic assumption to assume they’d graduate to become the developers of our current day... but it doesn’t seem to have been so. In my case, I never once even considered making software development a potential career - I only ever saw it as a hobby and nothing else. I didn’t know anyone around me who worked in tech, or as a developer, and it never crossed my mind that I could be one. Perhaps something similar happened with those other female hobbyist developers at that time as well, who knows? 🤷🏻‍♀️ I feel this goes to show just how important it is to get more minority representation out there, whatever the field, be it engineering, tech, finance etc.

I ended up studying the sciences, then went on to do engineering and finance in university. After spending some years as an investment banker, I quit as I knew it wasn’t what I wanted to do with my life, long term. Finally giving myself the space to think about what it is that really gave me joy and fulfilment, I set my sights on two things:

I really wanted to work in the tech industry (it was pretty obvious that it was eating the world, and I just love tech), but also...
I knew I wanted to be a builder (after years of doing advisory in a bank). Knowing how much I used to love programming, my decision to develop these skills then became a really obvious one.

Why a coding bootcamp?

Decision made, the next step was deciding how to actually develop the skills. My plan when I quit finance, was to go on a solo travel trip for 4-6 months. Before embarking on my trip, I signed up for a 5 day, intensive, front-end coding course (in-person coding courses / bootcamps were just starting to be a thing at that time). I learnt best practice HTML, CSS and basic JavaScript (with jQuery) and absolutely loved it.

I went off travelling, had a blast, and didn’t think too much about career choices or anything like that, for months. When I got to the point of starting to tire of living nomadically, at around the 4-5 month mark, and thoughts of “what next?” entered my mind, I knew that:

I wasn’t going back to finance; and
I wanted to give myself a few months to learn programming full-time, to see if this was really something I could realistically pursue.

That’s when I applied to a 3 month, full-time, in-person bootcamp in London... and it was pretty much one of the best decisions of my life. The thing to highlight though, is that bootcamps are definitely not for everyone. They’re also not cheap, so if you’re trying to make this decision, here are some bullets on why it was a good decision for me.

I’m an all-in or nothing kind of person (and bootcamps are definitely an all-in commitment). I don’t like doing things in half-measures. If I’m interested in something, I tend to immerse myself completely in that world, and can very quickly become obsessed with it. It’s true of a lot of my ongoing interests, and is both a good and bad trait.
- It’s good in that I feel like I progress quickly in the early days, which gives me forward momentum to continue learning (flywheel effect).
- It’s bad in that it’s all consuming in my life, and pretty much everything else takes a backseat for some time. What happens is that the fervour does eventually taper off, and I either drop that subject (e.g. investment banking), or it remains a core interest of mine, and I carry on progressing with it in more of a steady-state fashion (e.g. nutrition, health & fitness and drumming).
One of the main skills the bootcamp focused on teaching us was learning how to learn. The languages and frameworks taught at the bootcamp ultimately only serves as an introduction to the basics of programming. In the real world, languages go in and out of fashion, and you’ll need to chose the best one for the problem at hand, rather than the one you know. It’s therefore much more important to learn how to learn new things quickly.
I joined the bootcamp way before COVID was a thing. Learning in-person with other similarly minded folks really added to the immersive experience, as I was surrounded by others all wanting to learn quickly, and progress to the same goal. I was living, eating, sleeping and breathing code for, on average, 18 hours a days, for 3 months straight (and loving it!). It’s a lot like learning a spoken language - if you want to learn French, one of the fastest ways to do so is to go live in France and immerse yourself with other French-speaking people, 24/7.
Bootcamps are really focused on giving you practical knowledge. Keeping up with the syllabus meant I’d end each week with a working app. This was great from a GitHub portfolio building point of view, but also for building my confidence - it’s amazing to be able to mark your progress by interacting with programs you built by hand...and really satisfying. 😊
- Note that bootcamps are generally hyper-focused on ensuring you develop practical skills because a lot of them will also have a job referral function to help place you in a role after you graduate. This is great, if getting a software developer job is what you want. One downside is that focusing so heavily on the practical means a lack of focus on theoretical computer science knowledge that makes one a well-rounded engineer. The good news is that you can learn this in your own time, after you graduate.
Part of the syllabus involved teaching us programming best practices. This included usage of git and GitHub, Test Driven Development (TDD) and pair programming. You start by building good habits straight away.
The final 2 weeks of the bootcamp were reserved for final projects. It involved self-organising into groups of your choice, where you’d then decide on an app to build, build it, and finally present it to the entire bootcamp, alumni and businesses looking to recruit. It’s a practice mini-sprint with a deliverable at the end of it.
Bootcamps are an interesting place in the types of people it attracts. My cohort included people from really different experiences and backgrounds who I would typically never mix with. We were however, all united by the same goal...and having paid a lot of money to try to get there, were all super motivated to succeed. I was really lucky, and ended up meeting 2 people in the bootcamp who would become my co-founders upon graduating.

What the bootcamp isn’t

It isn’t personalised and the syllabus waits for no one. It’s solely up to you to keep yourself motivated and keep up with the fast pace of learning required.
Though bootcamps are catered for pure beginners, because there’s so much to learn, it’s unlikely that they’ll take you through HTML and CSS.
There was no handholding with the bootcamp I went to. In fact, it was the opposite where I was just dropped into the deep end. There was no homework. There was no exam. There were no marks. You put in as much or as little effort as you want. It was frustrating and it was difficult - you need to know whether you thrive or flounder in these types of situations.

Upon bootcamp graduation

Though it isn’t recommended, I started networking and applying for jobs before graduating (the reason it’s not recommended is because they want you to focus on learning how to program, rather than worrying about finding a job). As a result of this, I actually received a couple of job offers immediately upon graduating (so hey, bootcamp works! 🙌🏻).

I ultimately ended up going a completely different direction and started my own tech startup with a couple of friends I met at the bootcamp. Using our newfound coding skills, we created our MVP in a week, shipped it out for feedback, and went on our way! The main point to make here is to continue programming immediately upon graduation, and build real projects. This forward momentum is really important for habit building, to ensure you keep flexing your programming skills. Again, much like learning a language, you need to keep practicing until it’s ingrained, to ensure you don’t forget what you’ve learnt. 💪🏼

I was also lucky to effectively form my own group of developers to work and engage with. The process of continuous learning is easier if you have a supportive group to help you along...because the learning really starts at this point. Having to program to solve real-life problems for the first time really drove home the point that there were (still are!) so many things that I didn’t even know I didn’t know. It’s all good though, because the meta skill you get of learning how to learn comes in handy at this point. 😉

Next up: How I learn new things and continue to develop my programming skills.

P.S. Talk to me on Instagram, Twitter or https://bionicjulia.com!

Forem: Bionic Julia

Creating a React Accordion Component Using Just CSS

Using AMP Images in NextJS

AMP - Accelerated Mobile Page

How NextJS integrates AMP

amp-img component

Moving From React to React Native

But first...

Similarities

Use of the React framework

JavaScript eco-system

Differences

Runtime environment

Styling

Navigation

Deployment process

Github Actions Workflow For a React Native App

Defining when the workflow runs

Defining the jobs

Defining the steps within a job

Workflow for building and deploying a React Native production app

Improving Lighthouse Scores For bionicjulia.com

Starting point

Performance

Accessibility

After the improvements were made...

Performance

Accessibility

Summary

Accessibility Tips For Web Development

Screen readers

Accessible HTML

ARIA - Accessible Rich Internet Applications

Focus management

Visual considerations

Tooling

Creating a Sentry Logging Module to Set Context in a React Native App

Logging module

Setting Up React Native Jest Tests With Higher Order Components

How the helper functions will be used in practice

Breaking how the helpers file

Deeper dive into setting up Redux state

React Formik and Yup Troubleshooting Tips

Issue: If your form is pre-populated with data and validation doesn’t work on component mount

Issue: Not all field validations are working as expected

Issue: How to access formikProps outside the form component

Issue: Using React lifecycle hooks that are dependent on formikProps

A Guide For New Programmers (Part 3)

What I’d do if I was starting out today

Question 1: Why do I want to learn programming?

Question 2: What goal do I want to get to as a first step?

Question 3: What areas of tech / programming am I most interested in?

Question 4: What are the skills within this area that will best enable me to get to where I want to go?

Question 5: How should I prioritise the learning of these skills?

Conclusion

A Guide For New Programmers (Part 2)

How I learn new things and continue to develop my programming skills

Back to the bootcamp

Why meta-learning is so useful

Julia’s method

Step 1: Figure out the core concepts that underpin the foundations of what you’re trying to learn

Step 2: Practice those concepts in “real world” scenarios

Step 3: Structured learning

Step 4: Continuous learning

Miscellaneous tips

A Guide For New Programmers (Part 1)

How I Got Started With Programming

Back to the 90s

Why a coding bootcamp?

What the bootcamp isn’t

Upon bootcamp graduation

Issue: How to access `formikProps` outside the form component

Issue: Using React lifecycle hooks that are dependent on `formikProps`