< prev 25 Jan 2015 to 23 Jan 2015 next >

Posts tagged 'final project'

  • The ghosts of problems long dead

    Friday, I thought I had sign-in working the way I wanted. Saturday, I spent the day wrestling with the order that actions hit in Javascript.

    I am hesitant to say that I think I've got it, but it makes a lot more sense—no matter what path someone takes to a URL, make sure to bottleneck actions that need to take place in a certain order in order to make sure that everything related to cleanup happens when it should.

    Originally, the sign-in model we were given had login set with async: false, which is deprecated and rightfully so. A good portion of my day was spent looking at a repeated message from JQuery stating as much, and once I figured out what needed to happen—the user, on sign-in, throws a signIn event that other objects subscribe and respond to—I was most of my way to getting the interaction happening the way I want.

    This is a lot of wasted time, but I have to say that I really understand async events much better now, as well as pub-sub. Whenever I think I know what I'm doing, though, I learn more, so I'm reluctant to say that I know everything I need.

    One other thing happened in that was particularly frustrating. I removed my homebrewed utils directory from the manifest, only to change my mind and keep it in to be able to take advantage of a couple that I thought were useful. Well, for two hours I was getting weird behavior that, it turns out, was caused by my own implementation of router callbacks. Whoops, shit. I'll have to keep an eye on that sort of thing in the future.

    I've noticed that it's nice using a common naming scheme when creating files, but it often makes it challenging to figure out which show.js you need to be editing, or is throwing the error you're looking at. It pays to take the three seconds to verify what you think is happening is what's actually going on.

    I had a similar problem with Wordpress—I was making changes that didn't seem to be showing up in the final render, and I went down a lot of paths before I figured out that there are actually three different blog post views: all posts, posts by category, and single post. That's not DRY at all :(

    2:41 PM - 25 Jan 2015 in AppAcademy
  • Never have I been so happy to get a blank screen before

    Holy crap. I wasn't sure if I could do it, but I've got my app rendering a blank screen.

    Some elaboration is required.

    I set out today to get the basic infrastructure of Marionette working, with a modal login screen, and a router before action that properly redirects after sign-in.

    At 9:30 tonight, I checked in the last code that was necessary to get this to happen.

    I am so happy. I thought, when we were first learning Backbone, that it was pretty opinionated, but it turns out that it's flexible, and requires more configuration than convention. Sure, there are things that backbone-on-rails tries to enforce, but that's not Backbone per se.

    Marionette, on the other hand, has some strong opinions, but the documentation is sparse enough that it can be hard to discern what those opinions are. Nevertheless, it desires certain things, and after a lot of secondary reading, I have figured out a lot of what those things are. For instance, Marionette wants you to modularize everything, but the Marionette.Module object is pretty ghetto and is slated for deprecation.

    In the meantime, then, one can use standard JavaScript modules and so forth to add in modular portions of an app, or (as I have) simply expand on the backbone-on-rails opinions by adding a folder for (e.g.) controllers and inserting it at the correct point in app startup. It works for now, but I may have to refactor later.

    And what a statement that is! Every single line I wrote in Backbone felt like it needed serious refactoring, but everything in Marionette is so DRY. Sure, there's a bit more "needless" code to pass messages, but that is in keeping with the spirit of loose coupling.

    Case in point: I spent a good deal of time learning about JQuery Deferreds, which are a means of handling promises in JQ. They're similar in behavior to Arel queries—they don't do anything until you resolve() them, and until then you can keep modifying them by tacking on further attributes. Pretty cool, if you ask me, although a bit of a trip to wrap your mind around. When reading Essential JavaScript and coming across the section on promises, I didn't quite understand them, only really understanding that they help cut down on callback hell… but I saw the reason for them. Now I think I can consider them a part of my toolbox.

    What did I do today, then?

    • Marionette is starting up
    • I have created regions
    • I can attach subviews to the correct region
    • Calls to routes that require login are properly intercepted
    • Once login succeeds, the original route is triggered
    • Login is actually working :)

    What did I learn?

    • Reading the docs, while essential, can only get you so far
    • At some point (earlier than you [ed: meaning 'I'] think) you need to sit down and just break things
    • Initially, at least, you're not going to have a damned clue what you're doing, so you have to just get the gist and then try things.
    • Act more than plan. (This is personal, and in reference to my current state.)
    9:45 PM - 23 Jan 2015 in AppAcademy
< prev 25 Jan 2015 to 23 Jan 2015 next >