DEV Community: Alex Edwards

Where to go from here?

Alex Edwards — Thu, 30 Jul 2020 10:10:30 +0000

There are plenty of roadmaps out there if you simply google 'developer roadmap', but I also value the personal details and I'm in need of a bit of a review.

In the last few months of 2019, I quit my job, moved in with my folks to focus on learning Full-stack JS development, fell in love with Front-end, but really enjoy the puzzle-solving aspect to Back-end work. I've even started to enjoy writing tests.

Thanks to Kent C Dodds Testing-Javascript course! Highly recommend it for anyone who's looking to incorporate or learn it's value

I learnt React previous to the introduction to hooks, then I learnt it over again.

Since March 2020 when the lock-down hit the UK hard, there's been about 1% of the jobs going, most are senior / lead roles, and so as someone who's looking for their first 'real' role (I've dabbled here and there with paid work in the past).

So after some advice, to get Job-ready when they start coming back into the market, I've been learning Typescript (I ❤️ it!), Data Structures and Algorithms, GraphQL back-end (Found Nexus from Prisma and it's SO easy to work with!). Built a website in June with Gatsby, TS, and a CMS. Finished another project yesterday.

I'm not sure where else to go from here, should I continue building more projects, even if they're a bit copy-pasta using sites like [Frontend Mentor)(https://www.frontendmentor.io/) for visual queues? I have this bias that projects from courses are viewed a bit this way too - everyone producing the same project with minor differences.

I've learnt React, but is there value in learning Vue too? Vue3 is around the corner though not ready, I'm seeing it as a frequent feature in jobs advertised.

As Full-stack too, would I be wrong to invest in learning Python? Also tempted by IOS.

I'm constantly wanting to improve and thrive to do better, but as someone who values their time, I'm not wanting to go down the wrong direction or waste time, especially when the end goal is to get their first placement in a team and contribute to something more than just personal exhibition.

Got stuck in a hole, ended up revisiting a previous project - Accessibility Colour Palettes

Alex Edwards — Thu, 30 Jul 2020 09:45:19 +0000

It's coming up to nearly a year now since I took a leap to quit my full-time job (having gotten savings in place) and focus on learning development and get into my first job. I figured 2020 would be a start on a very long road to a serious outlook to this career (where I had only dabbled previously, with projects, and sporadic paid work.

Well, we all know what's happened to 2020, and the job market in the UK has all but dried up; advertised jobs have gone to about less than 1% of what it was before Covid.

So back in March, I've gotten some serious advice to get going on learning, certifications, projects etc. and be job-ready and skilled once recovery starts taking place. I've been learning Data-Structures & Algorithms, Typescript, GraphQL back-end, etc. I'm still pretty flaky with designing, but I'm getting there.

All of this while battling a somewhat depression ( us Brits are notorious for downplaying mental health, but in times like these, you've got to acknowledge it at least. I mean, I just quit an almost sure thing, personal-life stuff etc.)

Last month I built my own website using Typescript, React ( GatsbyJs ) and a GraphQL CMS. In the past two weeks I revisited an older project that I never completed and vastly improved it's functionality while not once referencing the old material.

My Color Contrast App is based on the idea of allowing you to pick your own colors, branding etc. but then being able to plug it into this react app to ensure that the colors align with one-another across the board. This way whether it's light/dark mode or even a multitude of different themes on the site, you know that each color's shade is the same and interchangeable.

I.e. red-100 has the same contrast to white as blue-100, green-100, etc.

This is important as Hex/Rgb is hard to read for contrast, and HSL's L value isn't a good value for contrast as greens are much lighter and blues are much darker regardless of the L value.

The Repo: github
The Live demo: Netlify

The Todos:

Design a mobile friendly version (Though, this is an edge case)
Implement Server-Side State with login credentials
Long-press on editor fields
Create download file / Copy CSS Custom Variables from State
Better Tests (I'm still new to testing everything, but I'm getting better)

What I'm stuck on:

I'm not sure the best way is to be able to dynamically create a downloadable file based on state. It's just a text file with a .sketchpalette file extension that will work with the Sketch Palette plugin.

Similarly, to be able to copy the state as CSS Custom Variables I've read somewhere I would need to populate a textfield with the state output, and copy from that rather than directly from a function?

I'm still new to testing, having only really worked on my website with tests and then this one too. I'm at about 95% coverage which I'm happy about as it covers as the User would interact rather than implementation, however, if anyone can point out major potholes I've missed, please, let me know! I'd love to be able to improve!

Other than that, if you have any comments on the project and other feedback, please, let me know! I'm kind of working in a bubble right now and explaining these projects to a non-tech family member, or a 5-month old puppy can be a bit one-way.

Parsing Markdown from a CMS

Alex Edwards — Thu, 18 Jun 2020 19:57:48 +0000

Parsing is a heavy topic, so this post is a bit code heavy, however, I'll try my best to explain away.

I'll save some time here; I spend 1/2 a day invested in getting MDX working with Contentful; I couldn't get it to work.

Instead, I figured after a moment, with Remark-Rehype, I can kill two birds with one stone. I can get Markdown to work, that covers 90% of my use case, and when I need another component rendering, adding custom components when required.

Rehype-React is the package that takes in trusted HAST and responds with react components rendered. HAST, as I had to learn, is an acronym for HTML abstract syntax tree. It breaks down HTML into an object that contains arrays of other objects containing properties and children.
Sounds complicated, huh?

Don't need to worry about it until tempted to write a plugin. Until that moment; this is the moment to change how that HAST turns into rendered code:

const renderAst = new rehypeReact({
  createElement: React.createElement,
  Fragment: React.Fragment,
  components: {
    h1: Heading.H1,
    h2: Heading.H2,
    h3: Heading.H3,
    h4: Heading.H4,
    h5: Heading.H5,
    h6: Heading.H6,
    p: Body.P,
    a: Link,
    ol: Body.OL,
    ul: Body.UL,
    li: Body.LI,
    blockquote: Body.BQ,
    table: Body.Table,
    th: Body.TH,
    td: Body.TD,
    hr: Body.HR,
  }
}).Compiler;

What's to be understood here is that unlike the Gatsby plugin for Rehype-React, this allows the given HAST to have custom components rendering its content. Passing our Contentful HAST into renderAst() we can ensure that each HTML heading, paragraph, and anything else follows suit with the rest of the site. That even includes anchor links that can and will take full advantage of Gatbsy's Link component.

Custom Link logic

To do that, we need to implement our component. I know, sounds counter-intuitive. However, if done correctly, we can drop in a different import and done.

First, we need to check the to or href attribute. Why? Because in our code, we'll pass in the to argument, however, our HAST will pass in href. Everything else will be down to what we give to them, or any additional parameters—aspects such as activeClass. All other logic will come from regex passed to the link.

First, let's see if it's an internal link by matching it with:

const internal = /^\/(?!\/)/

This regex looks to the front of the string for /, but not //.
If it's an internal link, it count be a download. So let's match it the response with looking to the end of the string. That's relatively straight forward too; the line starts with / and ends with '.(something), in regex that translates to:

const file = /\.[0-9a-z]+$/i

The $ is for the end of the string, and the + is to any combination of 0-9, a-z, in any amount.

The other difficult one would be a local navigation link. That's something that begins with a # or ?. It's difficult only for that it doesn't start with a / and won't work for accessibility if we pass in an 'onClick' prop.

const local = /^[#?]/

If none of that matches, then as a fail, return a bog-standard, standard anchor link that fulfils all accessibility and security concerns. All of it combined looks something like this:

import {Link as GLink} from 'gatsby'

function Link({ children, to, href, activeClassName, partiallyActive, ...rest }: LinkComponent): React.ReactElement {
  const internal = /^\/(?!\/)/
  const file = /\.[0-9a-z]+$/i
  const local = /^[#?]/
  const ref = to || href;

  if (!ref) return (<a {...rest}></a>)

  if (internal.test(ref)) {
    if (file.test(ref)) return (<a href={ref} download {...rest}>{children}</a>)
    return (<GLink to={`${ref === '/' ? '' : ref}/`} activeClassName={activeClassName} partiallyActive={partiallyActive} {...rest}>{children}</GLink>)
  }

  if (local.test(ref)) return (<a href={ref} {...rest}>{children}</a>)
  // All else, this is an external link
  return <a href={ref} target="_blank" rel="noreferrer" {...rest}>{children}</a>

}

Back to Rehype

We are dropping in this logic to Rehype so that within Markdown, we can link to pages, downloads, local anchors, external sites, and everything will work as expected. So far, everything else is purely stylistic (using styled-components). However, this option that Rehype exposes is key to quickly and easily integrating stylistic choices and translating Markdown into react components.

To fully utilise rehype, we now parse the HtmlAst field from any long-field text:

query Homepage {
  page: contentfulPage(title: {regex: "/homepage/i"}) {
    title
    blocks {
      ... on ContentfulPageHome {
        title
        subTitle
        authorBio {
          blurbTitle
          blurbDesc {
            childMarkdownRemark {
              htmlAst
            }
          }
          blurbLead

renderAst(blocks?.authorBio.blurbDesc?.childMarkdownRemark?.htmlAst)

Using renderAst() keeps components, pages, and templates clean as there aren't any further imports needed than our function, and generated code, writing integration tests or end-to-end tests ensure the output plays well with the code we write. Using styled-components can keep everything aligned when themes change, typography adjusts, and later in other components.

The last thing to address is images.

Gatsby Image with Contentful API

Thankfully someone, just like sourcing from Contentful, has already created a plugin for this. gatsby-remark-images-contentful will pull in any asset hosted on Contentful and allow Sharp to process images into fixed or fluid types to be used by gatsby-image. Under the hood, it works in a similar way to how querying an image would normally. Something like this:

profilePicture {
  fluid(maxWidth: 260) {
    ...GatsbyContentfulFluid_tracedSVG
  }
}

<Img fluid={blocks?.authorBio?.profilePicture?.fluid} />

Only images hosted on Contentful itself will be processed by images-contentful. Remark and Rehype will parse 3rd-Party hosts into standard image nodes.

Gatsby-Remark-Images is another option; however, at the time of writing this, installing alongside or installing instead of images-contentful causes problems. Namely doesn't accurately process the images from Contentful at all. Since I'm already utilising Contentful, I'm doubling down on image handling.

This post is an ongoing series along with my site development. All current process on my website and in the open-source repo is open for review. As I publish new features (Posts and Projects templates, changes in style), I'll continue to add to this series as a reflection of what I've learnt, and what reflections I have on the process.

Rendering a Page

Alex Edwards — Sat, 13 Jun 2020 15:19:45 +0000

In Part II I covered the prototyping and implementation of writing components, today I'm going to cover how to create Pages from Contentful.

For this, I had to learn precisely how Contentful manages its database-style CMS, how the source plugin pulls information, and how base to utilise it.

My thoughts behind the difference between Page and Template are quite simple:

A Page is purpose-built and has no ambiguity to what is displayed. Meaning a unique content-model for each and every page. A Template however, has to be generalised by design. A Template for my posts may include many different elements, components even, but I'll get onto that later. Likewise, some fields might be optional, but the key aspects need to be assured requirements. That might include elements such as a unique slug, or a publish date modifiable by the user.

The Model

'Top Level Page?' and Index came around because of a need in the code rather than instinct. Contentful generates its Indexes with UUID on every field; however, if it's a top-level page (think like a site map), then you would want to give it an index of importance.

The other two exciting fields are Meta and Blocks. Meta is another content model that exists globally. Ensuring that all content has the right information, and unique where needed, making sure things like publishing dates are correct, and slugs don't override each other.

Page Blocks are the unique aspect for every page. A new content model needed for every page.

My homepage needs nothing more than a greeting, subtext and a little about myself, which I'll include in my Author Bio; which in turn also houses all my social links and ways to contact me.

Okay, so now the content model is established.

The Code

Removing all the trailing curly-brackets, this is what I'm querying for:

query Homepage {
  page: contentfulPage(title: {regex: "/homepage/i"}) {
    title
    blocks {
      ... on ContentfulPageHome {
        title
        subTitle
        authorBio {
          blurbTitle
          blurbDesc {
            blurbDesc
          }
          blurbLead

For simplicity, I've removed some styling choices, but this is what it rendered as in my TSX file:

interface Props {
  data: PageHome
}

const IndexPage = ({ data } : Props) => {
  const blocks = data.page.blocks;
  const subBlack = blocks.subTitle?.split(' ').slice(0, 4).join(' ')
  const subColor = blocks.subTitle?.split(' ').slice(4).join(' ')
  return (
    <>
      <div>
        <h1>{blocks.title}✌️</h1>
        <h5>{subBlack} <span>{subColor}</span></h5>
      </div>

      <div>
        <div>
          <img />
        </div>

        <div>
          <h2>{blocks.authorBio.blurbTitle}</h2>
          <p>{blocks.authorBio.blurbDesc?blurbDesc}</p>
        </div>
      </div>
    </>
  )
}

Components with page queries necessarily have two elements to the file, the query variable, then the functional component that Gatsby passes the query into, via the data prop. Using Typescript, that data has an interface; otherwise, the TS Compiler will throw a hissy-fit. Typescript can get extensive, yet gives you complete confidence what elements are present, optional, and otherwise.

interface PageHome extends Page {
  blocks: HomeBlocks
}

interface HomeBlocks {
  title: string
  subTitle?: string
  authorBio: Bio
}

Some bits are missing here, such as the Page & Bio interfaces. However, each unique 'block' takes the original 'Page' with all the common elements and adds additional types where needed. Per the content model, subTitle hasn't deemed it as a requirement, so both interface and component need to cover that.

The next step is tricky, so I'll be covering that in its post; How I implemented rendering assistants to display typography, hyperlinks, and images into the code.

Writing the First Test & Component

Alex Edwards — Fri, 12 Jun 2020 16:00:21 +0000

Now that Typescript, Jest, and Cypress are set up and ready to go, let's run the site:

npm run setup

With the single command, npm installs everything runs the validate script which runs both Jest and Cypress one after another.

Nothing should happen at this stage, as there are no tests written. From a Test-Driven perspective, tests establish both how to interact with the module and what the outcome will be. Typescript is excellent for that documentation during development, but it won't do anything for runtime.

My site's going to feature a layout component that will wrap the site so that through page-change, elements in layout won't flicker or repaint. In my layout, there are SEO components; thank's to react-helmet, as well as a Header, and Footer component.

My Header will render with a title, and the main navigation for the website. That information will be passed in by Gatsby's graphql during Build time; so I know I need to mock the data passed into the component. Another aspect that would be useful to know is the current location path so that any styles are adjusted to show the current page.

Mocking Graphql with Jest .spyOn

Per gatsby's excellent documentation, it's as easy as statically declaring what information is present. GraphiQL is your friend here, as the data passed will be well structured and fields populated with the correct types. It will end up looking something like this:

const useStaticQuery = jest.spyOn(Gatsby, 'useStaticQuery');
useStaticQuery.mockImplementation(() => ({
  contentfulSiteMetadata: {
    description: 'Hello-Title'
  },
  allContentfulPage: {
    edges: [
      {
        node: {
          title: 'about',
          meta: {
            slug: "about"
          }
        }
      },
      {
        node: {
          title: 'contact',
          meta: {
            slug: "contact"
          }
        }
      }
    ]
  }
}));

By doing this, I don't need to worry about dependency injection. Instead, Jest will monitor the component, and use its mock data for useStaticQuery.

Queries and other APIs return generated data, so mock the returned value but not the implementation.

Ensure required elements are present

So writing the tests are now as easy as ensuring that the purpose of the Header component renders the right stuff:

test('It has a CTA', () => {
  const { getByRole } = render(<Header location={mockLocation()} />)
  const button = getByRole('button')
  expect(button).toContain(/contact/i)
})

or the better way of doing things:

test('It has a CTA Button', () => {
  render(<Header location={mockLocation()} />)
  screen.getByRole('button', { name: /contact/i })
})

Kent C Dodds' Pro Testing-Javascript course taught the method of testing how it's interacted with rather than it's implementation.

Writing the Component

Now that I've written the test, using it as a blueprint, we can get going with the component to make the test pass. In this case, laid out to use useStaticQuery and return a header element with a title present, a navigation element with links and a Call-To-Action button.

export default function Header () {
  return (
    <header>
      <p>Alex Edwards | {data.description}</p>
      <nav>
    {data.allContentfulPage.edges.map(page => {
      if (page.node.title === `contact`) return (
        <button 
          name={page.node.title}
          key={page.node.meta.slug} >
            {page.node.title}
        </button>   
      )
        {...}
    }
      </nav>
    </header>
  )  
}

Rerunning the test will pass this time because our component is returning the required elements. Now it's safe to add, modify, or refactor the code and keep Jest in watch mode to ensure all changes don't affect the requirements of this module.

Awesome tests to include would be using Jest-Axe to ensure all a11y requirements are passing, as well as Jest-In-Case to test through multiple props or data-values to ensure that different use cases return the right values, including error handling.

Other modules, such as my footer and other singular components, have similar tests associated with them. Elements like my Layout wrapper will have a different approach, called integration tests. The mentality is to ensure that everything works well together. Does the data passed from Layout to Header and Footer render successfully?

Later, the confidence gained from these tests will allow quicker development for pages, templates and the rest.

Creating my JAM-stack site

Alex Edwards — Sat, 06 Jun 2020 15:51:19 +0000

*Cover Picture by David Trivis on Unsplash

For the past two weeks, I've neglected to contribute to Dev because I've been hard at work trying to combine the tools I've learnt over the past month or two: Typescript, and Test-Driven-Development.

Since arriving back in the UK in September, I've been studying React, and it's various stacks ready to transition into a front end development job, and since Covid-19 landed early this year, I've been studying more and more. However, what's the point in studying if you don't put it to practice!

The Project Description
The Setup
The Content
A TDD Story

The Project Description:

Create a JAM-stack website utilising GatsbyJS (React), Typescript, and a CMS such as NetlifyCMS or ContentfulCMS.

Why Gatsby? Well, React is excellent, but with SPA (Single Page Applications), SEO and page speed can be a caveat. The way Gatsby overcomes this is to create static pages and then loads React in afterwards. That way, pages load quickly and accurately, and you still gain the advantages of a SPA.

Why a CMS? With Gatsby's incremental builds in Beta on Netlify, it can drastically increase build times for sites that have a lot of pages to render.

Typescript and TDD are the two aspects I've learnt recently, and that was the primary practice for the project. I've learnt to embrace Typescript with open arms; however, working with libraries can be difficult if they don't have Type declaration or feature it in their documents. It's mostly mitigated these days with the DefinitelyTyped project. And with TDD the idea is that you write tests (that initially fail) as a blueprint of the code, and later write code that fits within passing the tests. This way, you're not testing implementation, but you're testing how that particular function, class, or component will interact.

The Setup:

gatsby new new-starter https://github.com/lexedwards/starter-cypr-jest-ts

This starter was something of a bi-product of working with Gatsby. Once all the environment variables were in place, I saved it in another repo to use time and time again. It has Jest, Cypress, and Typescript fully supported, nothing more, nothing less. Since Gatsby uses a lot of configs under the hood, I imported my configs and tweaked them to get everything working together nicely. Partly workflow (Husky for Git hooks etc.) and somewhat getting Jest and Cypress working correctly together (Instrumentation injection for Cypress Code-Coverage)

The Content:

First hearing about Incremental Builds from Gatsby Cloud, later reading about it from a Netlify email, in beta. However, it's a significant change as with SSG (Static Site Generators) the major complaint is how slow build time can be. Hugo has gained massive momentum for how quick it's build time is. As of this time, only a handle of CMS' are supported, and that's what pushed me to use Contentful, including the option of writing markdown files within the Repo and importing them using Gatbsy.

Developer friendly, but with one pitfall, I couldn't quite get the Gatsby Contentful plugin to play nice with MDX. So, instead, I'm using Markdown with Remark-Rehype to convert to React Components rather than pure HTML. This way, if I wanted a component in my markdown, I would be able to write:

<my-custom-component></my-custom-component>

It's slightly different, however, having spent a day experimenting with Contentful and MDX with no avail, it's better than nothing.

One thing to note: With the Markdown on a CMS, there's no tie to what are valid components and so manual checking on the CMS would still be required. Rich-text might be an option here, but it's processing would be done by Contentful rather than Remark.

A TDD story:

It's all fun and games following tutorials, some of which I've followed in different forms, but first starting I had to remind myself so much to write tests first! It was a bit of a grind, to begin with, metaphorically slapping my wrists for diving into new components, however, a week later, writing unit tests was a dream for development as I was setting the behaviour and expectation before even thinking about tackling the problem. I'm still slightly nieve to how best to write tests, but the more I do it, the more I understand what's gaining better confidence.

test("Errrrrrr, I'm not too sure", () => {
  const {container} = render(<Component />)
  expect(container).ToBe('I don't know, that it exists?!')
})

Kent C Dodds' course was great for this, as this is my project, I've set the standard that my coverage of tests is allowed to be less than 100%. Testing Templates and Pages pool from components are End-To-End. Testing components as interacted with rather than implemented. Functions also, I don't need to know the function is adding 1 + 1 in a particular way, just that the result is deterministic and always equal 2.

describe('Navigate the Default Pages', () => {
  beforeEach(() => {
    cy.visit('/')
    cy.injectAxe()
  })

  it('Has no A11y Violations', () => {
    cy.checkA11y(null, {
      runOnly: {
        type: 'tag',
        values: ['wcag2a'],
      },
    })
  })

  it('Has Navigation', () => {
    cy.findByRole('navigation')
      .findByText(/about/i)
      .click()
    cy.findByRole('navigation')
      .findByText(/say hello/i)
      .click()
    cy.findAllByRole('heading')
      .findByText(/alex edwards/i)
      .click()
  })
})

*Test taken from my E2E test on my Index page

Rubber Duck Debugging My Git Flow

Alex Edwards — Mon, 18 May 2020 20:24:25 +0000

My head is 🤯 after investing the previous week in Kent C Dodd's Testing Javascript course (Very much worth the effort if you ever feel in doubt about testing confidence)

Today I took a step back and started looking at how I approach my projects, and my git commits in previous projects are an abstraction of that approach, where I would tackle big picture things in a single commit.

After having the boat-load of information absorbed, I needed a tangent to recuperate, and so I started thinking about the redo on my website that I'm going to tackle. I ended up getting distracted for a day on a Gatsby starter with some testing utilities like Typescript, Jest, and Cypress - that's for another day. For let's say the combination of the three led to some different configs (Looking at you Gatsby + Jest!) and type declarations (Jest & Cypress).

So today I got looking at how to integrate a TDD paradigm into my workflow, and as I've said, I typically look at my Git Commits for that. I used to be a sucker for directly injecting to my master branch 😅. However, I now know better.

So after a bit of digging into best practices and working with writing tests first, then code that will pass those tests; I present my rubber ducked flow. I call it that, because this is me, trying to explain git, TDD, and whatever else to the community while trying to solve my problem and coming up with the solution doing so.

So let's step through it;

GIT

Git is, in effect, a command-line based way to retain a different version of files. It can be run locally and sent to a remote repository like Github, Gitlab, or Bitbucket. This way, other people can utilise it to work together.

It isn't straightforward when you realise that there are many versions either in an archive or actively being worked. But don't worry about that just yet. Just focus on the small picture. Just know, that a reference to PR or Pull-Request is 'asking permission' to merge to different existences together.

Funny thing, I first used git to play KSP with my friends by sharing a repo of the save files and contributing different launch missions and ships. Super nerdy way to bring multiplayer to a game

TDD

'Test Driven Development' operates on the idea of writing tests for what you intend before you create it. Something like working in a traffic-light system you would say

🔴 Write tests of your intention.

🟢 Write code that makes those tests pass.

🟡 Refactor that code for optimisation or performance.

On top of that analogy, there are further four types of testing.

Static - Make sure there aren't any typos or type-errors (in Typescript). A common term for this is linting, like, ESLint etc. Most static tests are baked into, or plugged into amazing text editors or IDE's these days.

Unit - Does the code do what you think it does? Given two numbers, 1 and 1, the function returns 2 without doing anything else. Does it handle errors like passing a string rather than a number? Is the dom node filled out correctly with all a11y requirements for pure accessibility?

console: Give me a number, dummy!

Maybe it's a super functional and will accept an array of numbers too. 🎉

Integration - This is where your code plays nice with other code it's needing or interacts. With given data from an API, does the react/vue/svelt/HTML element do what you expect. As well as making sure the children elements are doing what they're supposed to.

End-to-End - From the developer's end to the user's end, is it all working cohesively? Can the user go through the motions of the site/app/program, and do that job-to-be-done without issue or error?

My Opinionated Workflow

Let me bring you back to my new flow in my projects going forward:

Git repos work like trees, a master trunk branches off different iterations of the same project. So from there, I've branched off release, develop, and develop/*. master only exists because of being automatically created at the beginning. So you see I immediately branch into develop and develop/*.

In the beginning, develop/* is where I'll live, writing unit and integration tests that will fail before nothing else. This branch is where I'll be blueprinting my intentions for the feature—ensuring that I've completed error handling too where necessary.

On this hypothetical chart, develop/[feature #1] (The Cyan coloured, 4th row) has a couple of commits. Here might be where I'm sharing my code with others asking for help (Another great use of shared remote repos!) and once I'm comfortable with my tests, code, and refactor, committing a PR to the develop branch.

Always make a new branch when wanting to make a change to something existing, and always PR to merge it back in

develop is a moment to check End-to-End tests. Maybe it introduced a new bug no present previously. My latest feature might create an a11y issue previously unseen.

Once everything is kosher, I can make another PR to the master branch to keep it as the one branch that is 'pure', where everything is working as intended and for my best knowledge, all tests are passing which means 🤞 - no bugs for the 90+% of users.

This mentality to my commits will also mean that my master branch might have code in it that's subject to change later, or yet utilised. Maybe this feature is purely integrating a service API or an algorithm, but its implementation is in a completely different realm.

In the chart, I also have a develop/[feature #2] branch, but the interesting one you'll see is that once it's gone through the motions, I have another branch. release. I'll keep this purely as an anchor point to where the master branch has everything that's needed to publish to the public. This way, I can keep on working on the next tests, the upcoming features, without worrying.

If I'm working on a project with Continous Deployment like Netlify, if I committed to my master branch, I could potentially send a request to Netlify to rebuild my website and publish these new developments that aren't ready for the public to utilise.

And there we have it; my rubber duck debugged git workflow!

I've started to enjoy these write-ups, I'm aiming for a more opinionated perspective than any tutorial. There are so many tutorials out there already that it wouldn't be beneficial for anyone. Instead, I'm aiming to document those moments of overlooked thought process when arriving at the result. Likewise, let me know your thoughts!

✌️

Putting Typescript into Practice

Alex Edwards — Wed, 29 Apr 2020 10:32:52 +0000

After a few weeks of studying and brushing up on areas like Data Structures and Algorithms, I've recently finished a course on Typescript. After this, I started to revisit my favourite side project: a WCAG-compliant colour palette app. I've been creating a Colour Picker UI component and realised that I wanted to break it off from the central system.

Why?

Well, two reasons:

I don't need the values from the colour picker to be cluttering my central app state.
I can easily add in a hook to relay the value object from the component, complete with methods that include pre-formatted values that work with the utility I'm using: 'color-convert'. So, without further delay, here's my little colour picker:

It's not entirely spit-polished just yet, as I've discovered styling range input can be a bit tricky. There's a slight bug within mobile browsers where the sliders' border is styled rather than the fill. However, I completely removed the component and was able to implement Typescript onto it. The UI is completely tied together, with the gradients adjusting visually, along with a hook that emits an object with hex, rgb, hsl, and lab colour codes.

Here's what I've learnt:

My typing hygiene transposing the component wasn't the best. My previous JSX wasn't the best at ensuring types, and the data passed; specifically my abstractions!
I completely forgot about the purpose of a *.d.ts file, so once I slapped my forehead for the oversight, VScode reopened all my files and told me to remove my explicit imports.
The new CRA --template typescript CLI worked wonders to get set up quickly, but I can't tell you how many times I was opening docs to find out what components were what types.

Most importantly, I found VScode was incredibly informative with errors. Suddenly my abstractions were too abstract and needed a rewrite, which made them more transparent. My state was interfering with handling invalid hex codes, and so I had to insert some middleware. All of this didn't run into errors in regular React + JSX; but given TSX, it made me double-check all my assumptions.

#2020 was a Non-Starter For Me

Alex Edwards — Fri, 24 Apr 2020 17:12:29 +0000

Something of a humbling experience, I left China in August '19 and ready to get back into Western life and a drive to get into Web Development and Software Engineering. I spend the past year studying what I could and building some smaller projects while learning. No Computer Science degree, no Boot camp.

2020 was meant to be the start of something serious for me, and then Covid-19 starting to take a grip on the world and hiring-freezing started settling in. My job alerts began drying up, and now here I am.

An inspiring conversation with a family friend in the job field, I got running again with patching holes in my knowledge and getting stuck into the events that were once in-person and now free online webcasts.

Now is the time to be taking this free-time and really developing what you can

So, I'm doing just that, I've scratched up on Data Structures and Algorithms, I've gotten my head around Typescript. I still have other lessons I want to learn like native mobile development, however, for now, I'm going for the spit-and-polish approach. I'm revisiting what I've learnt, old projects that I should have hosted online ages ago, and finally getting to grips with having an online presence again.

I'm sat on quite extensive notes, and without plagiarising any course or material that I've learnt from, I do think that everything that I'm learning is best shared online rather than sat as 1s and 0s in my laptop. Not to mention that technology moves so fast right now, that it'll probably be outdated by this time next year. Just like how searching anything outside of MDN or other well-maintained sources, you can find yourself looking at outdated or hacky approaches. I mean, just google 'centring with CSS'.

My First Post 🎉

Alex Edwards — Wed, 22 Apr 2020 11:23:54 +0000

Here's the first post, and I'll never have to write one ever again!

But it doesn't mean that I won't have other things to write.

TL:DR;

I chose an awful time to come back to the UK to change career paths after spending three years abroad. 2020 meant to be new employment, and then COVID-19 hit!

Back in 2011, I wanted to be a photographer because that's what I loved doing. I loved capturing moments and preserving them endlessly. However, what I loved doing (The old stuff with raw chemicals and wooden boxes) was a very niche market that didn't even inspire my tutors at University. Resources dwindled, and I slumped into my temporary bar job that turned into a full-time position, eventually turning into being part of the management team. Fast forward to 2016 and a said f*k it to the wind and went travelling with the money I had a single backpack that was 60% camera. A year later, I did a TEFL course and started teaching in Asia for two years to sustain a life in an atmosphere that was unapologetic 'no-expectations' & multi-cultural by default.

Some people thrive on that ladder of expectations and constantly unobtainable bar; I wasn't one of those at the time. The UK atmosphere at the time was to constantly side-hustle and over-work in a home that was falling apart but paid top-dollar for it. I'm sure a lot of places still are, but while travelling and trying my best to integrate locally, I found that it didn't have to be that way.

Aside: I'm a person that like to quantify changes or results, think of it akin performance testing or sanity-checking the effort vs result. I'm genuinely curious if learning languages or immersing yourself in other cultures re-wires your brain. I've found that I think very differently after this experience abroad.

I left China at the end of August '19, which wasn't perfect timing for me. However the country had gotten more hostile of foreign influence, and I'm sure everyone has seen some form of a headline about it over the past twelve months. Saved some money, visited a couple of places in Europe and spent the next few months finishing up the learning that I thought would be beneficial for the leap into Web Development. Something I had planned since 2017-2018. Well. That was the plan anyway.

So, after re-adjusting to the new situation over here, I've started again with learning industry demands, making comprehensive documents (I <3 well-written Documentation) and I'm going to try at-least to start giving back to the communities that have given so much already.