What I did today
- Started Wes Bos’ free course titled JavaScript30. I didn’t know there was one, but it’s good to have someone else do the roadmap and for me to just focus on JavaScript. I’ve not been one to like starter files but I so appreciate them now. How perspectives change!
- Some advantages:
- You train yourself to read, understand, and build a quick mental model of code someone else has written.
- With the grunt work done, you focus on just what you need to focus on. In my case, JavaScript.
- If you’re juggling several things, the time it saves you! Just go in and work through the problem statement… that’s immense.
- I worked on the Drum Kit exercise which was actually quite fun.
- I saw the
kbd
HTML element being used in real life for the first time! - Learnt about an audio element’s JavaScript interface. Specifically:
audioElement.play()
(method)audioElement.currentTime
(setter)
- Learnt about the
transitionend
event, which is pretty cool.
- I saw the
- This also seems to have inspired Chris Burnell to get started as well, which is really cool!
- Some advantages:
- I did not, unfortunately, work through the suggested improvements/exercises for the Tic-Tac-Toe game, as I thought I would do today.
- So… tomorrow it will be, then.
- I like that I’m doing this publicly which is forcing me to be accountable! Hoorah!
- Came across the seemingly simple grouping operator which has been used in a, say, twisted manner. Where? On an article explaining
this
, where else? 😛- If you open up your Node REPL and work through the following two snippets, you’ll see:
{}
returnsundefined
.({})
returns anObject{}
The grouping operator is supposed to give you control over operator precedence. But how is it doing what it is doing here?In the first snippet, it’s just a block with no references to any new variables in its scope, so it is destroyed pretty much immediately after being created.In the second case, why does adding the grouping operator cause the compiler to create an object instead?Yes, I’ve previously returned an object like so in an arrow function:const hurrah = () => ({
foo: "bar"
})
You want to return an object and not confuse the compiler with what it might misconstrue as a block (ultimately causing aSyntaxError
). Instead of our intention, which is to return an object. I’ve never thought about why this works either.So, why does the grouping operator force JS to return anObject
vsundefined
in the REPL for the two snippets above?Let me know if you do. If not, I’ll figure it out… eventually.
- If you open up your Node REPL and work through the following two snippets, you’ll see:
- I briefly read up on HOC which is a commonly used pattern in ReactJS. It kind of clicked for me today, at least in theory. Here’s how I understand it:
Take the example of CSS.
Maybe you’ve got an icon and you’ve got some data next to it.
Say, a clock icon and a text that reads the time it took for you to complete a task. You’d probably start out by naming it in BEM like so: data-metric
for the root component, data-metric__icon
for the icon, and finally, data-metric__datum
for the actual data.
data-metric
__icon
__datum
Now, even though this UI component was very specific itself, we named the classes as generically as we could. Why? So we could re-use them for other similar data metric we add later on.
HOCs are a similar pattern, except for React components (or any UI component in general in any framework/library). There’s logic that can be repeated for different components. So, you write a function that doe some magic stuff and then returns a new component — with its specifics all wired up and ready to use. It’s no longer generic.
You could say this is similar to the way, in principle, we add a modifier in a BEM class: data-metric--completion-time
.