learnable-content / functional-javascript-course

12 stars 14 forks source link

Made some notes #1

Closed craigbilner closed 8 years ago

craigbilner commented 8 years ago

Hi @mdavidgreen , these are my notes:

Don't think anyone uses double quotes in JS, single quotes?

1.6.2, 1.6.3

(original, replacement) => source => ...

3.1.0, 3.1.1, 3.1., 3.1.3 etc.

${greeting}, ${name}

3.1.3

// not sure what the FP teaching is here? function greet(...args) => args.filter(arg => typeof arg === 'string').join(', ') || 'Greetings';

3.3.0

greetDeeplyCurried = greeting => separator => emphasis => name => ...

3.4.2

curryIt(func, ...args) => (...subargs) => func(...[...args, ...subargs]);

4.1.0, 4.2.0 etc.

// constantly const const lengths

4.2.1

const getLength = obj => obj.length;

4.3.1 etc.

const numberOfLetters =

4.4.1

No need for brackets

4.5.0

Why put them into an array to join them at the end?

5.1.0

What does this do?

5.3.0

The bit in the comment :-)

5.4.2

const compose = (f1, f2) => (...args) => f1(...f2(...args));

mdavidgreen commented 8 years ago

Don't think anyone uses double quotes in JS, single quotes?

I do. Especially now that single-tick templates are an option. Double quotes make code easier to scan. JS treats them the same as single quotes (unlike CoffeeScript)

1.6.2, 1.6.3 (original, replacement) => source => ...

Good call. Thanks!

3.1.0, 3.1.1, 3.1., 3.1.3 etc. ${greeting}, ${name}

Makes sense to me

3.1.3 // not sure what the FP teaching is here? function greet(...args) => args.filter(arg => typeof arg === 'string').join(', ') || 'Greetings';

Demonstrating how higher-order functions work

3.3.0 greetDeeplyCurried = greeting => separator => emphasis => name => ...

Definitely worth showing as an alternative

3.4.2 curryIt(func, ...args) => (...subargs) => func(...[...args, ...subargs]);

Again, worth showing as an alternative way to build it.

4.1.0, 4.2.0 etc. // constantly const const lengths

I use let to remind me that a value is the product of an operation. I can explain that, and how objects and arrays can be defined with const and still be modified. I prefer let to keep those distinctions top-of-mind.

4.2.1 const getLength = obj => obj.length;

I made the variable names more descriptive

4.3.1 etc. const numberOfLetters =

Yes, less generic variable names

4.4.1 No need for brackets

Right you are!

4.5.0 Why put them into an array to join them at the end?

It's for demonstration. I don't want to distract the students with building a more involved example.

5.1.0 What does this do?

I updated the slide and broke out the two examples showing how higher order functions behave, explaining what the code does along the way.

5.3.0 The bit in the comment :-)

Yeah...

5.4.2 const compose = (f1, f2) => (...args) => f1(...f2(...args));

For this example, I don't want to go this far. I'm recommending people not try to build and maintain this functionality themselves

craigbilner commented 8 years ago

Thanks @mdavidgreen

Is 1.6.2 correct now?

On 5.3.0 I mean the commented code is preferable

On 5.4.2 not sure what you mean by going this far. I'd rather ES2015 all the things as it's much nicer to read

On the two style bits, unfortunately I think most of JS land disagrees and it would be nice to be consistent with what people should expect to see/write.

As more and more people use React and Angular 2, that put mark-up in JS, it's much nicer to have double quotes just for the template then single quotes for JS.

re: constantly const. I'm not really sure that's the intention from a language perspective, to use let if it's the product of something. const should be used when the variable isn't re-assigned, that's it...

mdavidgreen commented 8 years ago

Hi @craigbilner,

Is 1.6.2 correct now?

Yes, I think 1.6.2 is correct, with context provided.

On 5.3.0 I mean the commented code is preferable On 5.4.2 not sure what you mean by going this far. I'd rather ES2015 all the things as it's much nicer to read

I got it that you preferred the code in the comment in 5.3.0. Part of my video will involve explaining why I recommend writing first with the less concise, easier to maintain multi-line syntax, both in this example and in 5.4.2. My reasons include keeping code from getting too wide, limiting how much happens in a single line, and supporting simpler git diffs. I'll also explain that bytes can be saved by converting to tighter syntax if saving bytes turns out to be a real-world performance issue.

On the two style bits, unfortunately I think most of JS land disagrees and it would be nice to be consistent with what people should expect to see/write. As more and more people use React and Angular 2, that put mark-up in JS, it's much nicer to have double quotes just for the template then single quotes for JS.

I disagree about the appropriateness of always using single vs. double quotes in JavaScript, and I don't think I'm alone. I wouldn't want to teach people that it makes sense to adopt vanilla JavaScript practices designed to support style guides built around formatting certain elements in code that's going to be transpiled in specific frameworks:

re: constantly const. I'm not really sure that's the intention from a language perspective, to use let if it's the product of something. const should be used when the variable isn't re-assigned, that's it...

I've read folks like Remy Sharp recommending constantly const, but I disagree that it's the only correct approach, or the better approach. For teaching examples like these, I prefer using let when the variable may be reassigned, even if it isn't in a particular example. Let makes sense if the variable is being assigned a value that could have been legally assigned later because it is based on a calculation, or may change over time. In both of these situations, let reminds us that we're working with a mutable value, as opposed to a passed-in or preset value:

Thanks for getting me to think through these issues deeply enough to research them and put my reasoning about them into words. This has been fun. Now I may have to write some articles about these topics....

craigbilner commented 8 years ago

Thanks @mdavidgreen

Perhaps I'm missing something on 1.6.2 then as attitude take three arguments but you only pass two?

I guess as this is subjective we can leave it - my preference would be constantly const (as it parallels the principle of least power nicely and I'm not sure in these examples you need reminding that they're mutable).

Full ES2015 reduces the number of characters and makes the code look cleaner for me, ergo provides less cognitive load.

If you're dead set on this though, I'm not sure you should use wide code as an argument. I use the airbnb eslint config and still manage to fit all my code within their max length rule.

a =>
  b =>
    c =>
      d => 5

vs a lot of unnecessary function and return keywords. The git argument would then follow suit.

mdavidgreen commented 8 years ago

Good catch @craigbilner! I've fixed 1.6.2 correctly this time, I believe. Thanks for being my second set of eyes on this.

I hear what you're saying, and I do agree that the style issues are subjective and open to interpretation, depending on where and how the code is going to be used.

If the rest of it is good, I'm looking forward to getting started recording the lessons. Just let me know. Thanks!

craigbilner commented 8 years ago

@mdavidgreen go ahead, ta