Forem: Kris Guzman

React Server Components (Lingering Questions)

Kris Guzman — Fri, 12 Nov 2021 03:03:21 +0000

I watched the talk on React Server Components, and after all the excitement finally settled, I was actually left a bit confused. Hoping some smarter folks than I can shed some light on a few things:

"Server components don't render into HTML, they render into a special format" - Then what parses that special format into rendered HTML once it's streamed to the client? Does the React client side library do this automagically?
I understand that server components can be re-fetched when props change, while still maintaining the rendered dom on the client, but how are server components made aware of changes in props triggered in client components?
Anyone have any good reads on streaming rendering in relation to React?

Getting the Job: What's more important than technical skills?

Kris Guzman — Tue, 29 Dec 2020 11:00:10 +0000

As developers, we put a lot of merit on our own technical abilities. When we chase client work or go for that new job, we obsess over emphasizing our technical skills.

"I know how to build a scalable architecture!"

"I've used React, Redux, Vue JS, Express, C++, Java, etc!"

But what if I told you...

Your skills don't matter as much as you think.

Having interviewed several developers, as well as having heard feedback from client projects I've won, trust me, skills are rarely the key deciding factor!

So if skills aren't the most important thing, what does matter?

Personality

This is going to piss people off, but it's the truth. You are working with people, not robots, and people have the right to want to work with someone they can genuinely talk to each day.
When a client or interviewer asks what you like to do on your free time, it's not a test question. Don't tell me "I stay up to date with tech trends". If you like binging a certain Netflix series, share that! It's often a great talking point.

Communication Skills

This isn't the 90s. You need to be able to effectively communicate on a team, and this doesn't mean being able to explain your code to people. This is about taking the initiative to ask questions, contributing your own thoughts to conversations, and using your expertise to bring up potential issues that only you can foresee a developer.

Business Oriented Thinking

Many developers claim to have this, but few do. Business oriented thinking is the ability to put your developer intuitions aside and put business priorities first. Did you want to use a Framework X but Framework Y would get the job done faster? Go with Framework Y. Does that fancy animation in your header contribute any business value? No? Then drop it.

If you're going for a junior or mid developer position, you will probably do fine without this skill, but once you start aiming for higher positions, this gets increasingly more important.

For freelance developers seeking clients, this is everything. Get good at it, because this will get you where you want to be beyond your technical skills.

Passion & Genuine Interest

Every happy client I've had and job I've gotten was due to this. Being smart and talented are fantastic traits, but it won't necessarily get you as far as you might have thought. On the other hand, showing genuine interest in the client or company, the problems they are trying to solve, as well as showing the passion you have for your own work, those are the things that get you hired.

Conclusion

The fact is, everyone claims to have strong technical skills, and it is hard to verify those skills in a 1 hour phone call. Knowing this, interviewers and clients use other methods to determine whether to hire you over the sea of other "expert JavaScript developers" out there.

Not surprisingly, these methods often come down to, "would I like working this guy / gal"?

Does that sound unfair to you? Then you're thinking about it wrong. We live in a world full of people, and people are social creatures whether you like it or not. The sooner you recognize that, the faster you will find success (and dare I say happiness).

6 Things Programmers Can Learn From Writers

Kris Guzman — Thu, 10 Dec 2020 15:05:33 +0000

6 Things Programmers Can Learn From Writers

The art of writing actually has a lot to teach programmers about good software. Here are six tips you learn as a writer that can also be used by developers.

1. The First Draft Will Probably Suck

When writing, your first draft is usually… not great. As you get better at writing, the quality of your first draft will improve as well. Fewer and fewer adjustments will be needed over time, but the point remains: Your first draft will almost always be the worst version.

Programming is no different! Accept that your first draft is exactly that — a draft. That doesn’t mean you don’t put your best effort into it, but you shouldn’t be prematurely optimizing and spending a bunch of time “beautifying” your code. There is a high chance that no matter what you do, when you come back to your desk on the next go-around, you will have thought of a far better solution.

2. Proof Read Your Own Work

This is an obvious one. Anyone can usually tell when a writer didn’t even proofread their own work (spoiler alert, I didn't proof read this article!). The same applies to programmers.

Typos, leftover console logs, bugs so obvious you can catch them at a glance — these are all typically red flags in a code review that the programmer didn’t do much proofreading of their own work.

Proof testing your work is equally important. If you are submitting a feature as ready for user testing/review, make sure it actually works. Even if it's a one line change, I promise you that the one time you decide to skip the verification step, it's going to break something in the app against all odds.

3. Then Let Others Proof Read Your Work

Great writers usually have someone proofread their work. Sometimes no matter how much you look over your own work, you just can’t catch the obvious (or not so obvious) issues. Programming in a team is no different. The whole concept of “code reviews” revolves around this one idea of having others proofread your work to minimize problems.

4. There Will Probably Be a Second or Third Draft

When you had to write essays in school, how often did you submit your first draft and never have to touch it again? I assume (hope?) that has never happened. I remember having to revise my work two or three times before I was allowed to submit it as “complete.”

Programmers often tie their ego to getting their code right the first time (code interviews and competitions kind of push that).

Considering that an error-free piece of software has never been written, I’d say that kind of thinking will set you up for disappointment.

Your pull request may get rejected even when you think you did everything perfectly. That’s OK. You should be happy someone has given you the opportunity to learn and improve. We all have something to learn from each other.

Now, you may submit a second pull request and get rejected yet again. OK, I’ll admit that hurts the ego a bit, but it’s the same principle: Learn, improve, repeat.

5. A Finished Piece Is Better Than a Perfect Work in Progress

The article that is never complete will always be worse than the article never written. Have you ever not submitted an essay to your teacher because you were perfecting it and received an A+ as a grade? Hell no. You got a big fat F for failure.

Coding is absolutely no different. If your software takes two years to build because you want it to be perfect, you’ve probably already failed (and a year ago at that).

Accept that even your completed work won’t be a masterpiece and you will still be iterating on it long after you considered it done. The most important theme shared between writers and developers is that it is important to get feedback as soon as possible so we can make the necessary improvements sooner rather than later.

6. Keep a Cohesive Narrative

Have you ever read an article that can’t seem to stay on track? It’s like a roller coaster, but on a roller coaster, you enjoy the random twists, turns, and loops. In an article where all you want is information (or a good story), this is usually not desirable.

Something that requires a lot of skill in both writers and developers is the ability to elegantly flow the narrative from start to finish. To make the reader feel like they went on a journey, even if all they read was “I watched paint dry yesterday,” is part of what makes the top writers here on Medium so successful.

Programmers may be thinking, “Code should be optimal and easy to read — not tell a story.”

Is that so? What if I told you code that tells a story is easier to read? There is a reason humans are so responsive to a well-told story. Just check out this article on the psychology of storytelling.

When your code has a clear start, middle, and end, it naturally forms a story (an admittedly boring one), which makes it easier for other programmers to follow it.

If you really want to level up your programming skills, see if you can write code that is not only optimal but tells a narrative as well. I think you will find that others have a much easier time navigating your code.

Conclusion

Writing and programming have more in common than you may have thought.

See more connections? Add them in the comments section!

Better Way to Structure React Projects (Part 2)

Kris Guzman — Wed, 09 Dec 2020 15:25:45 +0000

In part 1 of this series, I talked about how to use the atomic design methodology to structure your React components.

It's safe to say that there was a lot of controversy around it.

Common Objections

This is nice on small projects but it doesn't scale.
I would go nuts trying to differentiate between an atom, molecules, organism, etc.
This is a design methodology, it doesn't work well in development.

All fair points. I purposefully didn't go into much detail in part 1, so if you had any of the concerns mentioned above, today is the day I address them.

Objection 1: This is nice on small projects but it doesn't scale.

A big concern is that many components either don't nicely fall under an atomic category, or are so domain specific that they can only be used in one place.

First let me ask you this. How often do you use a new JavaScript library, found the first example in the documentation, and it satisfied your requirements for small and large projects alike?

Probably not often.

The same applies to an atomic design folder structure. You have to adjust it to your specific needs.

Here are two ways I have used it on existing projects:

Option A - Add a "components" sub folder in each page

You might be hesitant to add yet another components folder, but in practice I found this to be very intuitive for developers. You have a "shared" components folder at the root. You can even rename your root components folder to "shared" if it helps separate concerns a bit more. The new components folder, specific to each page, contains one-off components with a lot of business logic that feel doesn't make sense to put in a shared folder.

A benefit of this approach is that it's easy to take your "shared" components folder and turn it into a component library with very little additional work.

Option B - Add a "domains" folder

This structure works particularly well for Next.js applications, since you can't add components to the pages folder without them being detected as actual web pages.

Objection 2: I would go nuts trying to differentiate between an atom, molecules, organism, etc.

This can get very subjective, but like any other organizational decision, how each level of components are differentiated should be agreed upon by the whole team.

It's okay if your definition of an atom and a molecule don't exactly match what Brad Frost defines as an atom and a molecule. Define it in a way that makes sense to you, your team, and your project.

How I categorize components changes from project to project, but here is how I approach it in general:

atoms
The smallest component I can create. Typically these are Buttons, Icons, Typography, Images, Text Fields, etc. It isn't very hard to determine what would make an atom. If you can't break a component down any further, you have an atom.

molecules
Components that are a relatively simple combination of atoms. They should have a very specific responsibility. Here are some examples:

A search field and submit button
A multi select dropdown
A product list item with an image, title, price, and description (or any kind of list item)
A snackbar component with a message, icon, and close button
A card component

organisms
organisms and molecules are the hardest to differentiate. I personally identify organisms as orchestration components. They tend to be more abstract, and control how molecules are laid out and interact with one another. This includes things like headers, sidebars, modals, forms, grid layouts, lists, etc.

In a simple world, you would keep application state out of organisms and let pages feed the actual data, but I found that this only works for very simple apps.

With that being said, this is typically the lowest level of components where I start injecting app specific state in order to keep a balance between performance and organization.

templates
Truthfully, I don't use this folder very much in practice on large projects. It can be very handy when you are using tools like storybook and want to mock entire parts of the application, or if you have an app with a relatively simple state structure, but I haven't found much value outside of that. By definition, you wouldn't want these components to manage any application state since that would defeat the purpose of it being a template. Consequently, it's hard to justify this additional layer on large projects, but if anyone has suggestions please share!

pages
This is one is usually clear cut. One thing I'll say about it is that if you can keep all of your business logic at the page level, then more power to you. It makes maintenance extremely easy, since your application state is in one place. However, this is pretty hard to implement in large, data driven applications.

My advice would be to try and keep your business logic at the page level for as long as you can, and only move things down layers when it's absolutely necessary. This should keep you from pre-maturely optimizing.

Objection 3: This is a design methodology, you can't use it in development.

... what? We can't draw inspiration from places outside of our domain?

Atomic design is a mental model that applies directly to Component Driven Development principles. In CCD, we want to start with the smallest, simplest components and build our way up until we get our end result: pages.

Atomic design encourages you to think in terms of composition. It's not a rigid set of rules. You can just as easily create some kind of analogy to legos, an orchestra (my personal favorite), or sports. Whatever floats your boat and gets the point across.

To say we can't use atomic design as developers because it's a design methodology just sounds lazy. If we as developers are doing our jobs right, we are designers as well, just at a different stage of the system..

Conclusion

I hope this cleared up some doubts around the use of atomic design in a development environment. I'm not saying atomic design is the all encompassing solution to your code organization problems, but it's definitely a handy tool to have in your toolbox.

How to Run Stripe Webhooks Locally

Kris Guzman — Fri, 04 Dec 2020 10:18:17 +0000

Today's article is going to be a bit niche, but nevertheless it's an issue I have run into on multiple projects and have finally reached a solid solution.

Note: This solution can be applied to PayPal, and any other platform that requires you to listen to webhooks.

The Problem

Stripe (and other payment solutions like PayPal) allows your application to listen to webhooks for all kinds of payment events (subscription updated, invoice creation, etc).

When trying to test payment events locally, we have to use our "live" test endpoints, since Stripe can only send events to a real server, not localhost.

This is a huge pain when debugging payments, since you have to deploy your test environment for every single change.

Also, Stripe only gives you two environments: test mode, and live mode. This ends up being pretty limiting for the common "local, dev, qa, prod" environment setup.

The Solution

We need a way to funnel webhook events to our locally running API. Luckily, some people smarter than I have created free tools for us to do this.

Install Ultrahook

What is ultrahook? It's an awesome, free tool that allows you to receive webhook events on localhost by funneling requests from the Ultrahook cloud (via your unique url), to your private endpoint (ex. localhost:8080). Once you try it, you won't ever go back.

If you haven't already, create an Ultrahook account to receive your API key.
Next, run gem install ultrahook on the command line. You may have to install ruby first by running brew install ruby on Mac, or perhaps this easy-installer for Windows.
Run echo "api_key: INSERT_API_KEY_HERE" > ~/.ultrahook so you don't have to pass in your API key on every ultrahook command
Run ultrahook stripe INSERT_DESTINATION_HERE, where the destination is your local endpoint (ex. localhost:8080/webhooks/stripe)

And that's it! Thank you Vinay Sahni for creating this!

Note for Teams

There are two approaches (that I've thought at least) you can take to get this setup for a team:

Let each member create their own ultrahook account, and as part of the onboarding process, they add their listeners to Stripe.
Use a master ultrahook account and share it with your team.

I think option 1 is the safer choice, although more tedious.

Create a New Stripe Account

This might seem a bit annoying, but it really makes your dev life easier.

I usually organize it as follows:

Main Stripe Account -> live -> production
Main Stripe Account -> test mode -> QA
Test Stripe Account -> test mode -> local

Enjoy the fruits of your labor

It takes a hot minute to set this up, but once you do, you will be so happy you did. At least I was.

If anyone goes with this setup, I'd love to hear about your experience! Any ideas for improvements? Let me know.

JS 101: Destructuring Assignment over Function Parameters

Kris Guzman — Thu, 03 Dec 2020 11:50:32 +0000

JavaScript: Use Destructuring Assignment over Function Parameters

With ES6 comes the ability to leverage destructuring assignment. For those who aren’t familiar with the syntax, it can seem a little weird. Once you understand how it works, I promise you will want to use it almost everywhere.

Quick Primer on Destructuring Assignment

Destructuring assignment with objects is just a way to take any JavaScript object:

const myFoods = {a: 'apple', b: 'banana', c: 'carrot', d: 'donut'}

And pull out the parameters we want into its own variable:

const { a, b, c, d} = myFoods

If we aren’t sure a variable exists, we can easily provide a default value:

const {a = 'apple didn't exist', b, c, d} = myFoods

If we want to rename one of the variables, we can do so like this:

// we renamed a to be apple 
const {a: apple, b, c, d} = myFoods

If we only want fruits (a and b without c and d), we can pick out the fruits and group the random foods by doing the following:

// you will often see "...rest" used as a convention 
const {a, b, ...otherFoods} = myFoods  
const carrotAndDonut = {...otherFoods} 

console.log(carrotAndDonut) // prints out {c: 'carrot', d: 'donut'}

And that’s all there really is to it!

How this will replace your function parameters

Lets say we have the following function:

function printFruits(apple, banana) {
    console.log(`we should have an ${apple} and ${banana}`)
}

Okay great, we expect an apple and banana. Let’s say we are using the same object as the one demonstrated in the primer:

const myFoods = {a: 'apple', b: 'banana', c: 'carrot', d: 'donut'}

We can use printFruits as follows:

// a corresponds to apple, b corresponds to banana
printFruits(myFoods.a, myFoods.b)

But there are a few problems here

First, order of parameters matters. The following can happen very easily and cause hard to track bugs:

// an innocent swap of variables can rain hell on our software
printFruits(myFoods.b, myFoods.a)

Also, what if we want printFruits to be smart enough to extract the fruits it expects and discard everything else? We could do the following using the ...rest syntax in ES6 (yes, it works for function parameters too):

function printFruits(apple, banana, ...otherFruits) {
    console.log(`we should have an ${apple} and ${banana}`)
}

But now we have an unused variable, which is yucky.

Okay, no problem, what if we just passed in the whole object like below:

function printFruits(myFoods) {
    console.log(`we should have an ${myFoods.a} and ${myFoods.b}`)
}

printFruits(myFoods)

That’s a little better. It solves the problems above, but introduces a new one by losing the clarity of the function signature. Before, we knew immediately that we needed to pass an apple and banana. Now we have to actually look at the function definition to see what we are trying to grab out of myFoods. Not so fun when your function spans 100 lines.

This is where destructuring assignments really shines. Here is what printFruits looks like using destructuring assignment:

function printFruits(myFoods) {
    const {a, b} = myFoods
    console.log(`we should have an ${a} and ${b}`)
}

printFruits(myFoods)

We can go one step further and actually use destructuring assignments right in the function’s parameters:

function printFruits({a, b}) {
    console.log(`we should have an ${a} and ${b}`)
}

printFruits(myFoods)

And if we don’t like the (purposefully vague) parameter names, we can always rename them!

function printFruits({a: apple, b: banana}) {
    console.log(`we should have an ${apple} and ${banana}`)
}

printFruits(myFoods)

As well as give a default value if we try to pull out a variable that doesn’t exist:

function printFruits({a: apple = 'default apple', b: banana = 'default banana'}) {
    console.log(`we should have an ${apple} and ${banana}`)
}

printFruits(myFoods)

If I’m using Flow or TypeScript, who cares?

Fair, but using this method (pun not intended) you can still free yourself from worrying about the order of parameters. Even in TypeScript, if you have two parameters that are both strings, you may accidentally swap them and be in an even worse position than non Flow / TypeScript folks because you trusted the system to catch that for you.

That being said, this is primarily for my vanilla JS folks out there who want a little more safety in their code. We shouldn’t let a type system keep us from doing our due diligence as not every project we come across as developers will make use of Flow or TypeScript.

Final Thoughts

I hope this helps shine some light on the practical benefits on destructuring assignment in JavaScript. There are plenty more applications, but this one I found to be one of the most common. Let me know your thoughts in the comments section!

A Better Way to Structure React Projects

Kris Guzman — Wed, 02 Dec 2020 14:56:13 +0000

First off, if you don’t know what atomic design is, I’ll give a brief primer below but I suggest you go to Brad Frost’s website and check it out.

Atomic design is Brad Frost’s methodology for building design systems. The idea is that we can take the basic building blocks of living things and give our UI a hierarchical structure based on it.

Brad Frost defines five main stages of UI components:

Atoms
Molecules
Organisms
Templates
Pages

Atoms are the simplest form of UI, consisting of things like headers, labels, input fields, buttons, etc.

Molecules are a combination of atoms that form more complex pieces of our UI, such as a search field with a submit button.

Organisms build on top of molecules and orchestrate larger parts of the UI. This can include a list of products, a header, forms, etc. Organisms can even include other organisms.

Templates are where our pages start to come together, giving context to all of our organisms and molecules by giving them a unified purpose. For example, a template for a contact page will have organisms for headers and forms, and molecules for text fields and navigation bars.

Pages, as the name implies, is our final page with all its content. The difference between pages and templates is that templates don’t provide any content.

Goal of This Article

I want to present a way to apply atomic design in your development workflow with the goal of making your code and project structure more maintainable, scalable, and intuitive.

Additionally, atomic design is a framework that can help bridge the communication gap between development and design. It is important that developers understand it so they speak to designers in a unified language.

When components are appropriately categorized, teams will be surprised to see how much more intuitive and organized their UI systems feel. Code is more maintainable, updates and refactors are easier, and on-boarding new designers and developers becomes a more efficient process.

Common Project Structure

Many of you are probably familiar with the folder structure below:

The idea here is that we try to keep components as “dumb” and as stateless as possible, while containers orchestrate our components and act as our pages.

I think we should get rid of this whole “container” vs. “component” concept for the following reasons:

It’s not scalable. We only have two buckets to dump our UI in. What happens when we have 200 components and just two categories? Exactly.
It’s not intuitive. What’s a container, really? Is it a page? Or is it just a stateful component? Where do the two meet?
It’s a dev concept, not a design concept. How can we efficiently cooperate with designers if we are speaking a different language? Designers aren’t concerned with stateful vs. non-stateful, they are concerned with application and relationships. How is the component used, and how does it relate to the rest of the UI?

A Better Project Structure

Why don’t we structure our project according to the stages of atomic design?

Notice how we put pages outside of our components folder. Intuitively, we don’t put pages in the same category as the other four stages. Pages are the final presentation, not the individual components themselves.

Also, I typically create a /forms folder inside the root organisms folder. Forms are super common so it’s a nice way to make your folder structure a bit more granular.

So, what do we gain here by making this small adjustment? Surprisingly, a lot!

Unified design and dev language. It is much easier to collaborate with your design team now that you are using the same lingo across the board. For my devs using storybook out there, this is even more beneficial.
Scalable folder structure. We now have refined categories for our components. It is much easier to keep our UI organized even if we have 200+ components.
Minimal project context needed. Normally, a new developer needs to have a good amount of context on a project in order to find components they need. With atomic design, the language and structure are more universal, so it is much easier to say: “Well, a header is an organism, so let me check the organism folder.”
Cleaner code. How, you ask? Well, atomic design forces you to better understand the relationship between your components. Even if you start with a big, messy, multi-functional component, refactoring is a breeze when you start thinking: “OK, where do I see organisms, molecules, atoms, etc.”

What’s Next?

Congrats, you have a rock-solid folder structure for your next UI project. Is that all?

Let’s fast-forward a couple of weeks. You have a few atoms, a few molecules, life is good, you’re thinking: “This is working out great! Kris isn’t so dumb after all!”

But then you hit a roadblock… You are building a complex component and aren’t sure whether it’s an organism or a molecule. Can molecules have state? When does a molecule become an organism? For that matter, where is the line between an organism and a template? A template and a page?

The lines between stages can get fuzzy in practice, so in part 2, we will take a look into how we can define these lines in a React project.

That’s all for this part, thanks for reading!

JS 101: Classes in Plain JavaScript

Kris Guzman — Mon, 30 Nov 2020 10:47:36 +0000

In my last article, I talked about how to implement the new keyword from scratch. Now we are going to take it a step further and re-implement a basic version of the somewhat controversial class syntax introduced in JavaScript. Why is it controversial, you might ask?

class Rectangle {
  constructor(width, height) {
    this.width = width
    this.height = height
  }
  size() {
    console.log(`${this.width} x ${this.height}`)
  }
}
class Square extends Rectangle {
  constructor(scale, width, height) {
    super(width, height)
    this.scale = scale
  }
  size() {
    console.log(`${this.width}px wide and ${this.height}px tall`)
  }
}

Looks pretty straightforward, right? I agree. However, there is one thing wrong with all of this...

The Problem with JS Classes

The problem with classes is that... well... JavaScript doesn't have classes! It's a language based on prototypal inheritance , not classical inheritance.

It's like trying to put a dress on a bear. Sure it will look less scary, but it doesn't change what's under the dress.

Don't be the guy or gal who uses classes thinking it works exactly like classes in Java or Python. Impress your hiring interviewer by understanding what's underneath! JavaScript classes I mean, not the bear with the dress.

Steps to implement classes in JavaScript

Let's implement our example above in plain old JavaScript without the syntax sugar. Here's what we will have to do:

Create our Rectangle constructor function with width, height, and size attached to this
Create a second constructor function called Square, which will call our Rectangle function to initialize parameters (this is the super(...params) line). It will also have a new member called scale
Make sure our Square "class" inherits the prototype of Rectangle as well by copying the prototype of Rectangle
Copying the prototype of Rectangle means Square.prototype.constructor will be Rectangle.prototype.constructor rather than the Square constructor we defined, so we must redefine the property.

Does all that make absolutely zero sense? No problem, let's go step by step with code.

Step 1

Create our Rectangle constructor function with petName and bark attached to this

Easy enough:

function Rectangle() {
 this.width = width
 this.height = height
 this.size = function() {
  console.log(`${this.width} x ${this.height}`)
 }
}

Nothing new here, just a standard constructor function as we would do pre-class syntax days.

Step 2

*Create a second constructor function called Square, which will call our Rectangle function to initialize parameters (this is the super(...params) line). *

function Square(scale, width, height) {
 Rectangle.call(this, width, height)
 this.scale = scale
}

This is where the confusion often begins. Why did we call Rectangle.call(this, width, height)? This basically says "call our Rectangle constructor function, but use the this parameter we pass in rather than the one in Rectangle. Also, pass in any other parameters expected by Rectangle." This is essentially the same is running super(width, height).

Our other member, scale, is exclusive to our Square class, so we assign it after we run the parent constructor function.

Step 3

Make sure our Square "class" inherits the prototype of Rectangle as well by copying the prototype of Rectangle

Square.prototype = Object.create(Rectangle.prototype)

What the hell is this? Great question!

In plain english, this basically says "I want the prototype of Square to be a copy of the prototype of Rectangle".

Okay, so you may be wondering now, why do we want to do this? Take the following example:

Rectangle.prototype.getArea = function() {
  return this.width * this.height
}

If we define the getArea method on the prototype of Rectangle, but forget to do step #3, our Square won't have access to this method. Why would we define methods on prototypes? You'll have to follow me and wait for the next article to explain that one!

Step 4

Copying the prototype of Rectangle means Square.prototype.constructor will be Rectangle.prototype.constructor rather than the Square constructor we defined, so we must redefine the property.

Our last step is an odd one, but basically if ran:

Square.prototype.constructor.name === Rectangle.prototype.constructor.name

we would see that they are equal, which isn't what we want. We want our Square to point to the Square constructor function, but because we literally copied the whole Rectangle prototype, we lost that connection.

So let's fix that:

Object.defineProperty(Square.prototype, 'constructor', {
 value: Rectangle,
 enumerable: false, // prevents this property from showing up for-in loop statements
})

Step 5: Profit

Phew! That wasn't super straightforward. Here is our final implementation:

function Rectangle() {
 this.width = width
 this.height = height
 this.size = function() {
  console.log(`${this.width} x ${this.height}`)
 }
}

function Square(scale, width, height) {
 Rectangle.call(this, width, height)
 this.scale = scale
}

Square.prototype = Object.create(Rectangle.prototype)

Object.defineProperty(Square.prototype, 'constructor', {
 value: Rectangle,
 enumerable: false, 
})

You might be thinking, "okay... nope I'm just going to use the class syntax", which is exactly why it was introduced in the first place!

The point of this article isn't to say "hey, classes aren't real so don't use them". The point is to understand what is really happening behind the scenes so you can make the educated decision between using class syntax or functions.

Coming Up Next on December 2nd...

We saw how classes are implemented in plain JavaScript, but what are the pros and cons of using the class syntax? Are there performance implications?

Follow me to find out! Or you can just google it I guess...

JS 101: Implementing the "new" keyword

Kris Guzman — Sun, 29 Nov 2020 12:49:23 +0000

Because there is no real concept of classes in JavaScript, it helps to understand what some of these classical keywords are really doing under the hood.

We're going to create a simplified version of the "new" keyword in JavaScript. For example, using the new keyword to instantiate an object we would do:

const dog = new Dog()

but we are going to do something like this:

const sparky = newObject(Dog, 'Sparky', 3)
const spot = newObject(Dog, 'Spot', 6)

What the "new" Keyword Does

To understand the "new" keyword, it's important to understand constructor functions. Constructor functions in JS are just regular ole functions that are responsible for initialization. For example:

// the upper case function name is just a standard practice, not necessarily required
function Dog(petName, age) {
   this.petName = petName
   this.age = age
}

So here are the steps that the "new" keyword does in the background:

Create an empty object
Assign the prototype of the empty object to the prototype of the constructor function
Run the constructor function using the "this" context of the new object
If the constructor returns an object, return that, otherwise, return "this"

Let's start off by defining a function called newObject that will replace the new keyword.

/* 
   We will need the constructor function, and all of the constructor
   parameters. Using the handy spread operator here.
*/
function newObject(constructor, ...params) {
 // we will fill this out in the following steps
}

Step 1: Create an empty object

Easy enough. Let's do that:

function newObject(constructor, ...params) {
 function d() {}
}

Step 2: Assign the prototype of the empty object to the prototype of the constructor function

A little trickier, but Object has a handy function called setPrototypeOf. Let's use it:

function newObject(constructor, ...params) {
 function d() {}
 Object.setPrototypeOf(d, constructor.prototype)
}

Not bad so far!

Step 3: Run the constructor function using the "this" context of the new object

Alrighty, this is probably the most complicated part for new JavaScript programmers. There is a function that all objects have called call and apply. They run a particular function where the this parameter of that function is the one we pass. For example:

function Dog(petName) {

   this.petName = petName
}

/* 
   we pass "this", so the "this" in "this.petName" refers to the one 
   we passed in.  
*/
Dog.call(this, 'Harold')

/* 
   if we want to pass an array of parameters, we can use the multi- 
   parameter equivalent of the "call" function.
*/
Dog.apply(this, ['Harold', 'James', 'Clark'])

Okay, so now that we know how to use call / apply, which one do you think we should use to handle step number 3? Remember, a constructor function can have any number of parameters.

Ready? Here it is:

function newObject(constructor, ...params) {
 function d() {}
 Object.setPrototypeOf(d, constructor.prototype)
// apply expects an array-like second parameter, which is why
// we spread it in an array
 constructor.apply(d, [...params])
}

Step 4: If the constructor returns an object, return that, otherwise, return "this"

To finish off our newObject function, we add a quick conditional check to see if the constructor function returns an object.

function newObject(constructor, ...params) {
 function d() {}
 Object.setPrototypeOf(d, constructor.prototype)
 const obj = constructor.apply(d, [...params])
 if(typeof obj === 'object') return obj
 return d
}

Note that null is technically an object, so if a constructor returns null, that will be returned by our instantiation function.

Step 5: Profit

Let's put everything together and give our function a whirl!

// our fancy new function
function newObject(constructor, ...params) {
    function d() {}
  Object.setPrototypeOf(d, constructor.prototype)
  const obj = constructor.apply(d, [...params])
  if(typeof obj === 'object') return obj
  return d
}

// an example constructor function
function Dog(petName, age) {
   this.petName = petName
   this.age = age
   this.bark = function() {
      console.log(`${this.petName} is ${this.age} years old`)
   }
}

const bill = newObject(Dog, 'Bill', 8)
const sam = newObject(Dog, 'Sam', 2)

dog.bark() // prints: Bill is 8 years old
dog2.bark() // prints: Sam is 2 years old

Conclusion

Now that we have seen how the new keyword works, we can appreciate how handy it is that all we have to do is type const dog = new Dog() to get the same result.

FUN FACT!

The new keyword will run the given function regardless of whether you type new Dog() or new Dog, so technically you don't need to do the former, but for the sake of everyone's sanity it's probably better to just go with the former option.