3/16 YOLOing in React

I don’t understand that title, either. I just don’t know what we’re doing today.

The ‘Do Now’ looks tricky. Justin wants us to write a function called sum()that has at least two of these features-

  • variadic behavior(using the spread (…) operator)
  • fat arrow syntax
  • .reducer

so that’s fun. I’m gonna see what I can do, but I’m not that beefy on any of these three. I will return to this blog after some time sobbing helplessly on my keyboard.

It went slightly better than I expected. Sean showed me how spread operators work, and I apparently already knew how fat arrow functions operate. The reduce part is kind of wrecking me, though. I can’t really get reduce to work the way I want it to. Justin’s about to explain it, though, I hope.

I did the homework for last night, with just a little bit of help from Master Kenji. I’m fairly certain he may actually be a magical leprechaun. If that dude doesn’t end up in a position of mentorship or education, the world will be worse off for it.

I think ‘magical leprechaun’ is redundant. Leprechaun is implied to be magical.

Ok, the ‘do now’. Laurent is the lucky winner to have his code up first. He wrote a simple sum() function that just did normal blank + blank, then he retroactively made it into a fat arrow function. His arguments were initially num1 and num2, so after making it fat arrow, he wanted it to be a spread operator, so he changed his (num1,num2) to (...nums)or something similar. Justin has suggested to put his function on one line, and to remove the ‘return’ operator. Apparently you don’t really need it with one line, since it’s an “implied return” or some crazy shit.

Yeah, if there’s multiple lines in your function, you have to tell it which line is the return statement, and you need to use curly braces. If it’s all on one line though, you can make it just look all nice and ‘terse’ like var sum = (...nums) => num1 + num2 , so that’s neat. I guess it makes the computer go all like “Right on, dudemeister, I see your line, and I raise you an implied return”. Because poker.

I just learned if there’s one argument you don’t need parentheses. You do need it with a spread operator though, so we’re using this here. The previously mentioned sum() may not work though, I’m a little worried about the num1 + num2 part. We’ll see what happens.

Ah, Laurent made it a for loop, to go over the array that is created when we sum() with a spread operator. I dig it. I considered doing that, but I wanted to make reduce() work for me. I should have probably done the for loop first, then tried to make it fancy.

Now Kenji is going to make it a forEach(). In sum() with spread and fat arrow, we’re going to make it nums.forEach(). Digression to explain forEach! Whoopee!

Ok, I can’t read the board, but I’m confident that once Kenji figures out where he hid his magical coins, he’ll properly explain how to use forEach in our sum() and I will promptly understand it.

Oh crap, they were explaining it while I was in leprechaun-land. Ok so the forEach looks like this now- nums.forEach(el => summation += el) return summation. Also, we defined var summation = 0 before that line, so we have a new variable to add that array to. We’re talking about the ‘el’ part, which I know means element. It means the same as nums.forEach(function(el) {summation += el})

So I was wondering where we had gotten that ‘el’ from, but I guess the fat arrow function made it its own name for that callback function. He’s going to write the source code for forEach, but since I feel pretty decent about higher-order functions, I’m going to take the opportunity to zone out a bit.

You know, I actually like everybody in this class. That’s usually not the case, you know? There’s always people in every, like, station in your life, that are irritating, or rude, or annoying, or whatever, but the whole class, bar none, are just really genuinely great people. Except James. He has popcorn fingers.

Ok, so I’m going to act like I don’t know what forEach does. From what I’m gathering of Justin’s current lecture over it, the whole schtick of forEach is to run a callback function on every element in an array.

Huh. I thought that would take longer to explain. I guess I could explain it in context. Ooh, let’s use our current thingie!

var summation = 0

nums.forEach(el => summation += el) return summation

So, what’s happening here, is the ‘nums’ there on line 2, is the inputted array. Inputted isn’t a word. Fuck it. The inputted array uses the forEach method, and inside the parentheses, we make a quickie anonymous function to tell us what callback function to use on each element in the array. It basically adds a running total(summation) to each element. So if the inputted values are 1, 2, and 3, those become an array of [1,2,3] due to the spread operator. Those three numbers are added to the summation variable in turn, like so- 0 + 1 = 1, 1 + 2 = 3, 3 + 3 = 6. So summation now has the value of 6, which is returned after completion of the function. I like explaining things, even if only to myself, but it is way more gratifying and learningable to explain it to others.

I like how I just spent all that time explaining forEach(), and we didn’t use it here. We used reduce(). Because fuck me. I’ll explain reduce() later.

You know, that’s not a bad idea. Maybe I make a whole blog post that explains every higher-order function, but in Barney text*.

  • Barney text means it’s explained in terms so simple, it can be understood by a 5-year old. We used this strategy in the army so that no dumb ass could possibly misunderstand a concept or order- “Ok shitbags, I’m going to break this down Barney style for those of you that have cognitive difficulties. ‘Cognitive difficulties’ means you’re dumber than Simmons’ father for not pulling out.” — then the instructions come, just as respectfully.

I don’t feel like writing the code out that is currently on the board for this ‘Do Now’ warm-up. It looks pretty and declarative and I get it, and I’m sure the rest of the class is getting reduce() quite excellently.

Ok, maybe I’m wrong. We’ve been going over this running total type stuff for quite a while, so I do believe I will make a blog post for higher order functions.

All righty, looks like he wants to go over ES6 syntax. Which will make Patrick very happy. I think he wanted to do this yesterday.

So we’ve always done var student = 'hank'. var will assign a key value type relationship. var is overwriteable, meaning that after student became ‘hank’, we can just say student = patrick anywhere else and it is now patrick. Also, var has ‘functional scope’. I think this means it can be used to assign a name to a function. We also know how we can’t use var outside of a function, but we can if the var is inside a ‘logical block’, like a rogue if statement or for loop.

Ok, now, alternatives to var. We’re going to start with const. I’ve asked about const before, and the way it was explained to me before was that const is about the same as var, but that it cannot be overwritten. Const in this context stands for ‘constant’.

Kenji asked about ‘hoisting’, whatever that is. I didn’t hear the answer because I was responding to a text from my friend’s super pregnant wife. She’s kind of, you know, emotional. Anyway, Justin is saying stuff.

He’s going over what I typed earlier about var, overwriteable, not able to be seen from inside a function, etc.

Ok, so that was var and const, so now let’s go over ‘let’.

‘let’ variables have lexical scope. This means they are secret when defined within any code block. I have so many questions.

Ok, so if (1 === 1) {let finalStudent = 'amanda'}, and you try to log finalStudent, it will say it’s undefined. Because, like we said about twelve seconds ago, let will be secret if it’s within any code block. The best place to use let apparently, is in for loops. Not really sure why, but okay, I’ll roll with it. I really want to smoke. I always want to smoke. I need to quit. I’m gonna quit!

Haha, no. I want to, but holy shit is that hard to do. I’ve only done that somewhat successfully twice, and once was because of basic training for the damn army. The other time was my ex being all like “I’m not going to marry you if you’re still smoking”, so I quit. For like a month or two, then I just hid it from her(somehow) for the last two years or so of our relationship. Yay for deception!

Justin is talking about ES6, about how it’s a Russian nesting doll of crap for the base JS language. Every new ES just adds to the previous lexicon.

Justin had us go on a break, and told us not to go smoke because it takes too long. Joke’s on him, I know how to powersmoke in like 3 minutes flat. Denis was talking a little about how he’s so exhausted from lack of sleep. I suggested finding a good balance for his life, between his physical needs and his necessary work output, but he said he ‘lost the scale’. I laughed my ass off.

Anyways, looks like we’re going back to the giphy app. I’m beginning to pronounce it like ‘jif’ in my head and I don’t like it. I’m going to actively reject that pronunciation.

So James is up on the code. Justin has given him explicit instructions to only code what people say to code. James ‘popcorn fingers’ Sewell likes to jump ahead/around.

We’re having James do something with the code that AWO put up yesterday. I think we’re going to try and merge the two codes, with what James had and what AWO had. He is CD’ing into his own giphy project, and then git remote add amanda urlwhere the url is amanda’s code.

Apparently AWO brought a “JS for Babies” book for Lizbeth, who is totes preggers. That’s super cute. Lizbeth isn’t here today, which is unfortunate. Justin thought the gift was for him from Lizbeth. Tsk, tsk.

ok, so. First James had to git initthen git pull amanda master. No, wait, he needed to remote add that first, like what I initially wrote up there. Justin is having us learn about ‘upstream’, which is how you can work on multiple remotes. I think. I’ll try and clarify later, James’ terminal is going all wonky.

Ok, not sure how, but we have merge conflicts. We’re going through to see if we can figure out what’s what. Kenji is going to walk James through the merge conflicts for the class.

So, we see two versions of the same code in several places. Git doesn’t know how to merge these all the time, so we have to determine which code we want to keep and which one to erase.

James just walked out with an ‘itch on his inner thigh’. He says it’s too awkward to scratch here. Pfft.

We want to keep Amanda’s code, since we know that one works. Kenji walked James(and by extension, the class) through the different conflicts.

All right, so Sam is up on the board. Justin is encouraging us all to contribute, as it will apparently take our combined skills to make this flux stuff work. I really like flux, I like how clear the data flow is.

I forgot to grab a cup for my sunflower seeds. I’m wondering if I can successfully use my Rockstar can to be a shell repo.

Ok, Justin is going over the data flow now. I missed the first bit, so now I’m not sure if I should wing it here or just listen and try to summarize shortly.

I’m gonna go for the can repo idea.

Something important-why is set the only way we’re allowed to update the STORE? It both modifies data’s state, and it triggers a publication of the event.

Sam is going to walk us through…something. We’re reviewing what is stateful about the app; trendingColl, and the activeID. So how does our app manage changes in the trendingColl? When our app first loads, what is trendingColl? An empty array. It is stateful because it changes.

Sam is going through the steps of our app as they act right now. I don’t feel like typing it because I must have typed it three or four times yesterday, and fuck that noise. I am, however, going to diligently pay attention to see if there’s anything I didn’t understand.

Nope, I’m good right now. Operation Rockstar Shell Repo is a mediocre success. It’s working, but is not convenient at all. However, it’s not so annoying that I will go out of my way to grab a paper cup.

In retrospect, I wish I had written down what Sam is going over. Me feeling like I’m 75% is not good enough to not write things down. If I’m not at 100% confident, I can always do with more support.

Ok, let’s mess with some CSS to make the gifs that are displaying on the page to the Strip on the bottom. Kenji is trying to introduce a package manager to Sam, so that scss is easier to read via highlighting different stuff.

So how do we get the gifs to display at the bottom, in a horizontal bar that is scrollable? There are a few elements to consider; an element class strip, and the element class gifs. We want strip to be block, which it is by default. We need to make the gifs inline-block though. So to make the strip stay at the bottom, we need to make the strip container a fixed position. Let’s find out how to do that in this shitty, shitty scss language!

We’re going to do some practice with dev tools, using it to update the CSS. Let’s start by styling the strip container, so he clicked on that div class in the elements portion of the dev tools. The .strip has position: fixed. Good. Now we set bottom: 0 so it’s at the bottom. We’re going to take out the max-height 30%. Now for the inline-block. Click the + for adding a style rule. In the .singlegif style, we now have display: inline-block.

The inline blocking still didn’t display them horizontally; the images are too big. Under .strip we display: flex. Also, .img we made max-width: 100%. Justin suggested this be a consistent thing we do across projects.

For anyone reading this, I very rarely go back to edit or proofread or anything. If I see a typo, I correct it on the fly, but I really want this to be super flow-y and more indicative of my natural brain processes so that I can be in the right mind-mold to re-render the material in my thinker.

God, I’m so eloquent.

Ok, so we’re taking display: flex off of the .strip. Now, we’re going to make .gif width: 20%. I was typing that previous bit so I don’t know why we took flex off. Oh well.

Overflow scroll time. Under .strip we will overflow: scroll.

Ok I have to use the bathroom. Damn that powersmoke, wasting my time.

Back. What’d I miss.

Ugh. Just check the scss file later. Frikin frakin.

Padding > margin

We want to click on one of the gifs, and that gif populates in the middle of the page, at a larger size, and the rest of the page goes all dark. We could also call this the detailView. Unless we already named it something else. In which case we will update accordingly.

Mooooving from Sam to Patrick. Justin wants us to focus on the functionality of the app instead of just the styling, so yeah. Justin is now trying to figure out why Patrick’s lappy is being such a bitch. It looks like his package.json is all jacked up. I have no idea what Justin is doing right now, I guess he has janky merge conflicts where he really shouldn’t.

Didn’t Justin say that debugging is like, 80% of a programmer’s job?

Ok, I don’t know if he fixed it, but he’s updating Patrick’s scss right now. Because life needs more scss.

I think I’m ready for lunch. I’m following all of this relatively well; it doesn’t look like we’re doing anything particularly new or mind-blowing, it’s more relying on previous shit we’ve learned to make this a fully functional, sexy looking app. I think for all future projects, both at TIY and beyond, I’m just going to make Sean do. Like, I’m gonna kidnap him. Lock him in my basement.

I don’t have a basement. Fuck.

Scratch that idea, I guess I’ll just learn how to be a developer.

Ok, Justin is still doing quickie scss stuff. Oh wait.

He’s gonna write some steps, then I guess we’re supposed to figure it out.

  • start with making the very first gif in the collection the active gif
  • give that gif position fixed and top: 50%, so that we can at least verify that it has been made active.

So the goal at the moment is just to make sure we can make any gif our bottom bitch, and the easiest way to do that is just to take the first gif in the collection.

So we want to set the activeID once we receive the collection. We can do that in the ACTIONS. It’s the opportunity we have to make a gif the activeID.

In our Actions.fetchTrending(), after the trendingColl key-value pair, we make a new KVP(first we are seeing what the path is to the collection ID’s) and we end up with activeID: trendingInstance.models[0].get('id')

Get it? We’re making the activeID on the STORE the same value as the trendingInstance.models[0].get(‘id’).

So where is this information now? It was set on the STORE, which was broadcast, and the STORE’s data became the StripView’s state.

You know, I haven’t drank nearly as much coffee this week as I have before, and I’m a lot more productive. I don’t know if that’s causative, but it’s interesting.

Patrick just told me he wishes he was as attractive and talented as I am. I get that a lot.

So all the gifs are going to hear who is the activeID. They will check it against their own ID, and only the one that is equal to it will be the active one.

Kenji had Patrick write in the Strip div, under gifCollection, activeID={this.state.activeID}

Patrick is off, and Sean the…uh…Bomb, is on. Yeah, Sean the Bomb.

Justin just relayed an embarrassing story about grad school and getting one’s period.

We just passed activeID to the Strip, now the Strip is responsible for passing down to the gifs.

So we’re in Strip, in StripView file. In the return for GifComponent, after gifData, we will activeID={this.props.activeID}

Moving down to GifComponent. GifComponent now has the activeID. Every gif class now knows who is the bottom bitch. Hank came up with the idea for a ternary statement, before the render function. It will check if the gifs id = the active id. Then we will give that div a different classname, one that we can mess with in scss. Ternary statement as follows-

var gifClass = this.props.gifData.get('id') === this.props.activeID ? 'single-gif active' : 'single-gif'

It’s like, if it’s me, I will be single-gif active. If not, I’ll just be single-gif. Magic, fuckers.

Back to scss. Rrgh. Ok.

.single-gif.active{position:fixed;top:50%}

I’m not explaining that scss. It’s pretty clear. Justin wants us to finish the scss tomorrow, after the speaker.

Now we’re going to make the gifs clickable, and change the active-gif to the one that we click. Laurent will captain the ship after we figure out some errors in his code. I’m gonna pontificate for a moment.

I’m actually kind of glad I didn’t blog like this the whole class. Some thoughts don’t need to be recorded for posterity. Ever gone back to your teenage journal? All that angsty shit that makes you cringe now? It’s a god damn tragedy, right? Imagine that, but now everybody is looking over your shoulder as you read it. Fuck that mess.

Ok, back to work. We’ve pretty well automated the process of this app. We don’t have much functionality left to deal with. Pretty much just the clicky shit. So who is going to have the onClick method? The GifComponent sounds good. Inside of defining the div, before the class name, we’re going to put our click function in.

So above the render function in GifComponent, we will make a custom method called _handleClick that will tell us what to do with the clicking.

In order to change something stateful about our app, we must update our STORE. To do that, we need to use an ACTION.

We’re going to pretend we have an action and invoke it in our _handleClick. It looks a little like ACTIONS.setActiveID(this.props.gifData.get('id')), and now we can define that method in our ACTIONS file. That method will pass in the ID of the gif it clicks.

(sidebar-I’m having more fun than I ever have in this class. This blogging crap is making my brain actually do what I want it to do. I feel…happy.)

setActiveID: function(gifID){STORE.set({activeID: gifID})}

Oh hey, it works. We added a bit more scss, but our gif that we click on is now popping out like a boss. Practically lunch time. I might actually be able to take the day off today, maybe just do some light coding of previous projects in React/Flux. For fun.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.