Javascript programming every day of the week

Two great tastes... ...Not so much.

One part of the Hack Reactor program that my developer friends say is really accurate, in terms of preparing you for the real world, is the "Legacy" project. For four days, you and a team of three to four other people get to build anything you like, using any techs you like. Then comes the "Legacy": for four days, your team picks up another team's project and builds cool stuff out from their starting point. How do they techs they chose work for different people going in a different direction?

In my case, not 100% perfectly. So there was this day that I wasn't sure about how to dynamically generate a dropdown menu with Angular... I tried various methods and they weren't working... Eventually I tried just a straight-up, bog-standard <select></select> tag... Even that didn't show up...!

As you can probably guess from the title, the answer is, MaterializeCSS was not the right fancy CSS framework to use with a constantly shifting thing like Angular. Here's the Stack Overflow answer where someone gives a proper sermon about how MaterializeCSS falls short.

CSS/front-end frameworks make it easier to build a website that shrinks and bends well on a mobile phone, and that looks fine without a lot of poking. In fact, often these days you can look at a website and tell what it was made with, because developers are pretty happy to leave it as it came out of the box. MaterializeCSS is an attempt to look like Google's "Material Design" styles... Same paper-airplane-looking arrow for Submit/Send, etc.

However, apparently, MaterialzeCSS does some of its magic by overwriting normal HTML tags with its own... And any of its own things that require JavaScript to open or drop down or pop up must be initialized when the page loads... And anything that changes after the page loads LIKE SAY when a call to a database returns and populates a dropdown menu with options... Just doesn't happen.

Good times, good times.

You can see the website we worked on here: http://teslalegacy.herokuapp.com/ (If it takes many seconds to load, that's just because we're hosting it for free, and Heroku takes awhile to find it if no one has been there for half an hour). To see the glorious hand-crafted pop-up-div-full-of-checkboxes that I used instead of a drop down menu, you have to log in with GitHub. (Setting up a GitHub account will be worthwhile for you, anyway, but that's a story for another day.)

Remembering these from last week: Challenge 3 was another I'd done before, "find the longest word in the sentence", and I got a few more refinements in my answer: I used a regular expression to create the first array; and (having discussed it with Ben) I used an empty string as the initializing value. The previous stab at this Reduce, where I was trying to initialize with 0, was comparing apples and oranges in the form of numbers and strings.

function LongestWord(sen) { 
  var arr = sen.split(/(\w+)/g);
  var foo = arr.reduce(function(prev, curr){
    if(prev.length < curr.length){
      return curr;
    } else {return prev;}
  }, '');
  return foo; 
}

Looking over other answers, I think reduce is by far the most elegant path. Wooo! Arrays FTW!

Challenge 4 was ...a journey. ( Read more... )

I've been sick this past week, which didn't stop me vs. 6.1 and 6.2, but when I hit 6.3 I couldn't even figure out what he was asking. It's like he's saying, design a protuberance on the center of your face, then use that protuberance to detect a scent. ...Does he mean find your nose, or does he mean build yourself a new nose? That second one seems a bit unnecessary. Or to be less metaphorical, what am I missing? Iterating over arrays and objects seems like a major portion of what we've been doing so far. The emphasis on interface has got to be meaningful, but the gap between that text analysis and understanding the reason behind the question is fairly daunting.

I'm posting now because I at least figured out something, though I'm fairly sure I'm deep in the weeds heading in a direction that would baffle and amaze all who came after me.

I wondered what methods came baked in to objects, like forEach does on arrays. So I googled, and found this StackExchange bit, http://stackoverflow.com/questions/5842654/javascript-get-objects-methods

which lead me to screw around in JSBin seeing what came included in the Object package,
console.log(Object.getOwnPropertyNames(Object)); and
console.log(Object.getOwnPropertyNames(Object.prototype));

And then there were all sorts of interesting things to look up:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object

Moving forward with Object.keys, I tried this out as a start of an attack on 6.3, adding the console.log stuff in the midst of the program when it initially didn't return what I expected. Thanks to my housemate Ben for that general technique! What I was trying to do here is to get it to pull out a value from a Seq object at any given point:

var Seq = function(object) {
this.object = object;
};
Seq.prototype.valueAtI = function(i) {
var keyArray = [];
keyArray.push(Object.keys(Seq));
console.log(keyArray);
for (var j = 0; j < (i || keyArray.length); j++) {
if (j == i)
return keyArray[i];
else
return "There are fewer things in the sequence than that";
}
};

var foo = new Seq;
foo.bar = "baz";
foo.bear = "bearz";
foo.pear = "pearz";

console.log(foo.valueAtI(1));

The results were [[]] / There are fewer things in the sequence than that . I'd varied the value of i, even down to 0 ("undefined"), but it was the second set of brackets that tipped me off. Less broken code below:

Seq.prototype.valueAtI = function(i) {
var keyArray = Object.keys(this);
console.log(keyArray);
for (var j = 0; j < (i || keyArray.length); j++) {
if (j == i)
return keyArray[i];
else
return "There are fewer things in the sequence than that";
}
};

This actually results in an array of the keys of the object. It doesn't do what I meant it to do, and I think I can see why now that I'm writing, but it's pretty late and I'm taking the tiny win.