Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript fundamentals before learning React

robinwieruch.de

Post reply on HN
Print view View original

31–40 of 72 posts

Re: JavaScript fundamentals before learning React

#31

Post by cygned »

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!

I think, the most important aspect I tell my developers is to not define functions inline during render. So, do not do this:

     this.smth() }>
This creates a new function every time the rendering happens and mutates the prop onClick on every render. Once you have a component with a lot of elements (e.g. inputs) and child components that check for changes props to determine whether to render, this will get you in performance trouble.

We do not use class arrow functions but instead have helpers to bind specific functions to the component's context or generate setter functions.

Re: JavaScript fundamentals before learning React

#33

Post by michael_michael »

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!

I am learning React and ES6 currently. I dove into React before really understanding ES6, and your article is really helping to illuminate some of the dark corners of JS. Thank you.

One section I was hoping would get more treatment in your article (like the same treatment you gave classes, which was great) was imports/exports. Named vs. default exports are kind of baffling for a newcomer, and the usage of the named import with curly bracket syntax seems completely arbitrary.

I am sure there are many, many good explanations of named vs. default imports/exports out there on the Internet, but this is one that leaped out at me. I was a little disappointed that the section on imports/exports was so comparatively short. It mostly discussed the usage of imports/exports in CRA.

Still, awesome article. Thanks again.

Re: JavaScript fundamentals before learning React

#34

Post by mygo »

ravenstine wrote: post #19
pygy_ wrote: post #6

Earlier quoted context omitted.

Hi, Robin. Then you may want to say that `const` guarantees that the name will remain bound to that object. The great-GP is correct in that `const` has nothing to do with immutability besides that. It doesn't necessarily conveys an intent of inner immutability. It just states that whatever is in the variable will stay there until it goes out of scope. Using `const` whenever possible is good advice, off course.

It's been astonishing to me how people switched from var to let, but seem confused as to when to use const. I use const wherever I can since it's more appropriate for non-changing variables, and it helps me more easily visualize how a variable is being used in a block. But in other people's code I see a lot of letting all over the place. Maybe it's because of those articles saying to use let instead of var, but gloss…

maybe it’s because const is 2 more letters to type.

if “let” was “letitbe” I bet const would be more popular

seriously though, I wish they could have chosen a 3-letter word for const in keeping with var and let. I know const exists in other languages, but it doesn’t even mean the exact same thing as some other languages anyway.

Re: JavaScript fundamentals before learning React

#35

Post by yorwba »

sorahn wrote: post #29
Touche wrote: post #27

Earlier quoted context omitted.

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.

OK, you caught me, give bar an argument. (I'll edit the gist) Why should mocking only be used in 'extreme circumstances'? I want to test what bar does, and I don't care what baz does, and if someone breaks baz, my unit tests for bar shouldn't fail, because it is doing its job. I would mock it if it was calling some function in another module, so what's the difference if it's calling another function in the class?

Mocking a component means that you now have two places where that component's behavior is specified and they can diverge. To prevent that, you'll need an integration test where the components interact directly. Just not using a mock is enough to get such an integration test.

Then the value of the original, mocked unit test is questionable. It only provides additional information in the event that the mock differs from the actual component. If that's unintentional, then either the component is wrong (which should be caught by the tests for that component) or the mock is wrong. In either case, the mocked test provides little or negative value.

Then the remaining case, where mocking is actually useful, is when the mock intentionally shows different behavior. Mocking a slow computation to return the result instantly. Deliberately failing, to test error-handling code. Simulating unlikely events in general. Those are good uses of mocking.

TL;DR: Write more integration tests instead of unit tests with mocking.

Re: JavaScript fundamentals before learning React

#36

Post by _uhtu »

ggregoire wrote: post #24

Another basic ES6 trick that beginners usually don't know: handleChange = event => { this.setState({ [event.currentTarget.name]: event.currentTarget.value }) } So you can handle 10 inputs with the same handler.

This is great, and a strategy I used a lot in my last code base. If you do this for statically typed JS though, you'll get either error messages or bad typing with lots of `any`s and weak type checks.

Here's a great strategy to do the same thing with strong static types, like in flow and typescript:

  setTextField = (name: 'name' | 'email' | 'phone') => (event: InputEvent) => {
    this.setState({ user: { ...this.state.user, [name]: event.target.value } });
  }
  
  setBooleanField = (name: 'isCool') => (event: InputEvent) => {
    this.setState({ user: { ...this.state.user, [name]: event.target.checked } });
  }
  
  render() {
    
    	
    	
    
  }
More verbose than the non-typed version, but simpler than declaring a function for every field with all the goodness of strong static typing.

Re: JavaScript fundamentals before learning React

#37

Post by wongma »

cygned wrote: post #31
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!

I think, the most important aspect I tell my developers is to not define functions inline during render. So, do not do this: this.smth() }> This creates a new function every time the rendering happens and mutates the prop onClick on every render. Once you have a component with a lot of elements (e.g. inputs) and child components that check for changes props to determine whether to render, this will get you in perform…

I usually do this when I need to pass arguements in:

   this.smth(arg) }>
How can I do this without defining a function?

Re: JavaScript fundamentals before learning React

#38

Post by tills13 »

wongma wrote: post #37
cygned wrote: post #31

Earlier quoted context omitted.

I think, the most important aspect I tell my developers is to not define functions inline during render. So, do not do this: this.smth() }> This creates a new function every time the rendering happens and mutates the prop onClick on every render. Once you have a component with a lot of elements (e.g. inputs) and child components that check for changes props to determine whether to render, this will get you in perform…

I usually do this when I need to pass arguements in: this.smth(arg) }> How can I do this without defining a function?

isn't that functionally equivalent to `onClick={ this.smth }`?

Re: JavaScript fundamentals before learning React

#39

Post by sorahn »

yorwba wrote: post #35
sorahn wrote: post #29

Earlier quoted context omitted.

OK, you caught me, give bar an argument. (I'll edit the gist) Why should mocking only be used in 'extreme circumstances'? I want to test what bar does, and I don't care what baz does, and if someone breaks baz, my unit tests for bar shouldn't fail, because it is doing its job. I would mock it if it was calling some function in another module, so what's the difference if it's calling another function in the class?

Mocking a component means that you now have two places where that component's behavior is specified and they can diverge. To prevent that, you'll need an integration test where the components interact directly. Just not using a mock is enough to get such an integration test. Then the value of the original, mocked unit test is questionable. It only provides additional information in the event that the mock differs fro…

> TL;DR: Write more integration tests instead of unit tests with mocking.

Interesting. I will investigate what that looks like at work tomorrow. Thanks!

Re: JavaScript fundamentals before learning React

#40

Post by mikekchar »

allover wrote: post #12
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…

'const prevents reassignment' is a much simpler way of saying that. Mutability doesn't need to come into it.

While it is simpler, I think it's better that people actually understand the difference between a reference to a value and the value itself. "Pointers are hard" is a statement that many beginner programmers make, but if you don't understand the concept, you will always be limited as a programmer.

And whether you say "can be reassigned" or "mutable" (which means exactly he same thing, BTW) it doesn't really matter. JS has some surprising mutability rules. Variable references can either be mutable or not (depending on const, let or var), however function parameter references are always mutable (which can cause much hilarity in some circumstances).

Even values are a bit strange at times unless you understand what's going on under the hood. It's obvious that boolean or number values are immutable, but it's less obvious that string values are immutable; even more so since it doesn't throw an error (at least in V8) when you try to mutate them. You might assume that function values are immutable (how could you mutate it?), but because of closures, they are completely mutable (as long as the values being closed over are mutable). And, well, functions are also so-called "object" values in JS (which I still think is not a good idea, but I understand why they did it).

While, it is more complex to discuss that separation, it's valuable when you get into more difficult discussions -- especially if you are trying to write mostly pure functional code, with a few non-pure bits for performance. You need to be able segregate the pure from the non-pure and if you are passing closures, for instance, it's super important to understand how mutating a value in one place can essentially infect something that you thought was pure.

Post reply on HN