Posts tagged 'marionette'
-
One of my hangups about continuing work resolved itself over the past couple days. I ended up having a couple of redundant checkins—"Fixes data model", "Data model finally fixed"—but I think I'm there now.
Collections have models, and certain models, like
Posts, have collections of their own (in this case, comments). When you pull the data from the server for a non-root page, the data needs somewhere to "hang" so as not to face sync problems. So, when I fetch a post, I shouldn't fetch the class it belongs to, I should instead examine the post's section_id property, and then put that in an existing class's post collection. … Got it?User -> Sections Collection -> Section Model -> Posts Collection -> Post Model
So, on fetch of the last item in that chain, I need to go to the head of the chain and request that this data goes in the proper place in that chain.
It took me a while, but I think I ironed out all the kinks. It took moving some logic from the models into the collections: if you ask a
Postwhat section (class) it belongs to, it asks its collection, which in turn had that property set upon initialization. (I also needed to start initializing new collections with(null, options)instead of({}, options)because it turns out{}is a model on its own, just one with no attributes… derp.)What does this mean? A whole bunch of crazy sync problems disappeared all at once, and I can finally see the light at the end of the tunnel. I have never truly had a Minimum Viable Project (MVP), and I'm getting to the point where that feels possible, and likely to happen soon.
-
Now that we don't have to blog, I can blog whenever I want—which also means blogging in the middle of the day when I've found some solution to a particularly knotty annoyance and am taking a break from whatever.
I'll try to keep this quick, and I still don't have it how I want it.
Sign-in is handled through a modal (using a library that is just okay…). When the app first starts, it tries fetching the
currentUsermodel (asynchronously, of course). Meanwhile, it tries to route to whichever route was input, and if the user isn't signed in (which he won't be, because we're still waiting on a server response), it redirects to the sign-in window, which has an initializer that tells it to destroy itself when it receives a'signIn'event over the Backbone.RadioeventsChannel.Meanwhile, the modal animates, and only adds its keybindings once the animation is finished. But the
'signIn'event is received in the middle of the animation, which means that the view isdestroy()ed before it has attached its keybindings… which it does after the fact.Long story short, when a signed-in user refreshes the page, the sign-in modal installs listeners that get uninstalled before they're installed, and the next time the user hits "enter" the modal executes a "submit" event on empty text fields.
I got around it by having an
onShowcallback that checks to see if we're signed in, and ONCE THAT CHECK HAPPENS, install the'signIn'event listener. If that check fails (we've signed in during the 100ms that the animation has as default) then we uninstall ourselves.Gah. JavaScript, why you hurt so much?
-
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 asignInevent 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.jsyou 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 :(
-
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
beforeaction 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-railstries 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.Moduleobject 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-railsopinions 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.)
-
I did make headway finding employers today, which is good. There are quite a few that I can tell are doing things I would enjoy, now that I know how important user interactions and a strong API are to me. All the glue in the middle is not so interesting, which suggests, me being me, that this will be my first role out in the real world. Lol.
Most of the work just involves reading corporate copy and trying to suss out what it is that a company actually does. I will say that if I can't understand a company after two or three reads, they don't go on the list at all.
As for the rest of the day, I spent a lot of time stressing out about getting my project portfolio together. I still don't love my final project, but I started doing some major refactoring late yesterday afternoon and well into the night, and even though I haven't tested what I'm writing as much as I'd like I know that I prefer Marionette.
My project won't be done in the way I'd like, but as long as I can show it off, it should be okay.
This is stressful.
-
Yesterday, Tommy asked to sit down with each of us at some point this week, to see where we are and what we're working on. I grabbed the first slot, and basically asked him "so, what are we supposed to be doing this week?" The list of tasks is pretty daunting at the moment, but today I feel like I'm getting a better handle on everything that needs happen in the forthcoming weeks.
In short: I need to figure out how to best identify jobs to apply to, I need to compile those into a "roadmap" of places to apply, I need to (at some point, starting next week) apply to them… and to prepare for that, I need to get my portfolio, resume, and cover letter together.
Speaking of that, I did some work on my personal website (where you're reading this) (ed: this is no longer true; I'm on a different site now), and learned quite a bit about how Wordpress works. It's okay, but I still kind of hate PHP. In time I'll probably get it more to my liking, but it's functional now, at least.
Again, the coming priorities are portfolio and job searching, and how daunting they are! I've decided that I have more to do than Backbone can handle, so tonight I started reading into Marionette. It's not something that happened as a lark; I found myself doing so much repetitive stuff in Backbone, and the solutions I found always seemed to lead to Marionette anyway. Finally, tonight, upon turning my attention to my final project again, I found myself installing three plugins to add functionality that Backbone didn't have and that I didn't much feel like writing… and said, to hell with this, I'm going to do it right.
It looks like a pretty good drop-in add-on to Backbone, so I'm pretty confident about the possibilities. I told Tommy, though, that I'd have it together by Monday, which is going to take a lot of my time. Here's hoping.