What I Did!

I recently ran through a boot camp's two-hour video where I built and deployed a fullstack application.

It only took me SIX-HOURS ...

Here are some of my takeaways.

1. Proper patterns and conventions on inline CSS is difficult.
2. Refactoring was not taken into account.
3. Using the Node Server to push the React Build is awkward.
4. There were no Unit Tests.
5. Deployment was a simple external hook.

None of these bad, strange, or odd patterns were discussed.

The Good

There were good things.

• Use of Context to handle Light and Dark Mode.

I need to look into other component libraries to see if this pattern is implemented there; is something similar for Angular and Vue?

Why Did I Do This?

I wasn't intentionally looking to see if they were teaching good or bad practices. I was looking to see what NodeJS, React, and deployment patterns were being used.

I did this for my own learning and development as a professional.

I wanted to see ...

• What was being taught about React?
• What was being taught about NodeJs?
• How were they deploying the application?

These are things that I do every day.

And, I'm always looking to improve my skillset ...

I just wanted to see if I was doing it right (I'm generally the expert that people reach out to) - Imposter Syndrome might have been kicking in.

There were a lot of issues that bothered me (mentioned above).

Issue: Inline CSS

I don't just copy/paste code while training. I type it in (completely) to allow finer control and better learning.

When I was entering the inline CSS, I found an issue ...

... and, that issue was what really bugged me as I watched the remainder of the training.

As I entered an attribute name, sometimes I pressed TAB and sometimes I entered the whole attribute name followed by an equal sign (=). This resulted in two different patterns that do the same thing.

export function TestComponent() {
  return (
    <Text
      fontSize={"xl"}
      textAlign="center"
    >
      No Products Found
    </Text>
  );
}

In this context, fontSize and textAlign are doing the same thing.

Standards and consistency when writing code are important. When your code is organized and clean, it’s much more likely to stay that way over time.

Additional Experience (Clean Code)

In client code, I see ternaries nested in ternaries; I couldn’t tell you how deep. A simple case-statement, if-else structure, or object-pattern can make the code significantly easier to read and work with.

I saw the code above; again, I'm not calling anyone out.

Let's look at a simpler example.

const H = (C == 0 ? null :
    V == r ? (g - b) / C :
    V == g ? (b - r) / C + 2 :
             (r - g) / C + 4
    );

With this nested ternary, it's nearly impossible to follow the logic.

This code can be cleaned up and improved ...

let H;

if (C == 0) {
  H = null;
} else if (V == r) {
  H = (g - b) / C;
} else if (V == g) {
  H = (b - r) / C + 2;
} else {
  H = (r - g) / C + 4;
}

I'm not 100% sure what the logic here is supposed to do, but I can follow these if-else blocks more consistently than the nested ternaries above.

The import of consistency cannot be overstated; it’s a fundamental basis for clean, manageable code.

Issue: Lack of Refactoring

In this simple codebase, there were several places where code was repeated.

const { success, message } = await updateProduct(pid, updatedProduct);

console.log(success, message);
if (!success) {
  toast({
    title: 'Error',
    description: message,
    status: 'error',
    isClosable: true
  });
} else {
  toast({
    title: 'Success',
    description: 'Product updated successfully.',
    status: 'success',
    isClosable: true
  });
}

The code above shows a success-failure pattern that was repeated throughout the codebase.

It could easily have been abstracted to show a simpler way to handle success or error. Even if this code wasn't cleaned up, it should have been mentioned.

Issue: Node Server hosting React

I've seen this pattern used recently at an enterprise-level client.

It bothered me when I saw it there.

It bothered me when I saw it in the video.

This pattern isn't scalable.

1. The React code is static and can run in any cloud bucket.
2. The NodeJS code can run as a Lambda or Function App with only minor adjustments.

... then, they become truly scalable.

As presented, ... the student would never see that other options might be better and more performant.

Issue: No Unit Tests

There wasn't even a mention of Unit Tests.

Granted, this was a simple application with relatively easy-to-understand code.

But, ... this code could benefit from some rework to make the components more testable.

At a minimum, ... they should have discussed places to test and tools to use for testing so that the student had more information on what to look for in the future.

Issue: Deployment as a Hook

Deployment, where Render watches my repository for changes (hooks into it), isn’t a bad pattern.

There’s no control over the deployment pipeline, which I had been hoping to see.

I was disappointed, but this issue is minimal.

Learning the basics of DevOps is an important part of understanding the whole development process.

Summary

I am specifically not mentioning the boot camp or video that I watched. This article isn't meant to call anyone out directly.

I want you to see where things could be improved.

None of these bad, strange, or odd patterns were discussed.

1. Proper patterns and conventions on inline CSS is difficult.
2. Refactoring was not taken into account.
3. Using the Node Server to push the React Build is awkward.
4. There were no Unit Tests.
5. Deployment was a simple external hook.

I have major concerns:

• That newer developers would see the code used in the video as the right way to do things.
• Without context, this will leave them and their company at a disadvantage.

This article will most likely become a video, conference talk, and/or a workshop series.