JavaScript fundamentals before learning React

Post by chocolatemario » Fri, Jul 20, 2018, 1:55 AM UTC

Swizec wrote: post #3

wild_preference wrote: post #2

This article has a lot to offer a JS + React beginner so it feels lame to reply to some tiny part of it, but this bit is a constant error propogated in the ecosystem: > Even though it is possible to mutate the inner properties of objects and arrays when using const, the variable declaration shows the intent of keeping the variable immutable though. let and const only control mutability of the reference. They say noth…

Beginners don't know about references. What you say is exactly what the author meant.

Post by dvlsg » Fri, Jul 20, 2018, 2:13 AM UTC

sorahn wrote: post #18

rwieruch wrote: post #8

Hey, author here :) I am curious about your experiences using/learning React. Are there any other JavaScript topics which are important when starting out with React? Would be great hearing your opinion!

It’s worth noting that using the fat arrow syntax for class functions make them exponentially harder to unit test because they do not exist on the Prototype of the component, but are instead only initialized when the class is initialized. If you are trying to unit test a function that calls another function in the same class you cannot mock the second one it if it is a fat arrow.

Post by sorahn » Fri, Jul 20, 2018, 2:24 AM UTC

dvlsg wrote: post #23

sorahn wrote: post #18

Earlier quoted context omitted.

It’s worth noting that using the fat arrow syntax for class functions make them exponentially harder to unit test because they do not exist on the Prototype of the component, but are instead only initialized when the class is initialized. If you are trying to unit test a function that calls another function in the same class you cannot mock the second one it if it is a fat arrow.

I feel like testing things by replacing pieces of a prototype would be fairly fragile anyways. Is there a reason you couldn't use some form of composition to mock / abstract your dependencies instead?

Post by Touche » Fri, Jul 20, 2018, 2:35 AM UTC

sorahn wrote: post #25

dvlsg wrote: post #23

Earlier quoted context omitted.

I feel like testing things by replacing pieces of a prototype would be fairly fragile anyways. Is there a reason you couldn't use some form of composition to mock / abstract your dependencies instead?

Given this super contrived example: https://gist.github.com/sorahn/2b287c2a97a12e318585e84d9a9e8... If 'baz' was a fat arrow function, you would never be able to test bar in isolation. for example: Jest is set up so it's super easy to say `jest.spy(Foo.prototype, 'baz').mockReturnValue('whatever')`and test that bar is doing the right thing.

Post by sorahn » Fri, Jul 20, 2018, 2:42 AM UTC

Touche wrote: post #27

sorahn wrote: post #25

Earlier quoted context omitted.

Given this super contrived example: https://gist.github.com/sorahn/2b287c2a97a12e318585e84d9a9e8... If 'baz' was a fat arrow function, you would never be able to test bar in isolation. for example: Jest is set up so it's super easy to say `jest.spy(Foo.prototype, 'baz').mockReturnValue('whatever')`and test that bar is doing the right thing.

Mocking should only be used for extreme circumstances. This class is very easy to test without mocking. `bar` takes no arguments and has no external dependencies and therefore should always return the same result.