Dec. 16, 2011 by alen code
As mentioned earlier, we've been working away on the next version of Pin Drop and finally it's out there and in the app store. But that's not what this post is about. It's about
One of Django's best features is its straightforward request dispatching based on URL routing. It comes with a drawback though. Every time you navigate to another URL, you get a full page refresh. This is not ideal when working with maps and markers. We needed to create a JS UI that wouldn't refresh and reload everything. It would have to hold a reasonable amount of state: pins, filters, settings, categories, navigation, etc. With a little effort and thought though, we were able to build the frontend almost like we would build the backend in Django.
The recommended way is to assemble UIs in Backbone.js using its View class and then bind DOM elements to handler methods. It requires handling a lot of events and also removes the nice mental mapping of URL to function.
Eg: building a form requires subscribing to its submit event. When the event is fired, the data needs to be extracted out of the form. Then the event must be cancelled to prevent it from bubbling up. Using Samy.js instead, we can simply create a route and will receive the whole data as an object literal when the form is submitted to the defined URL.
It looks nice and completely frees your head. Sammy takes over any route that you define. No manual binding and handling. Just normal server (or client) generated HTML.
Let's expand the code a little more to have an actual naive API to work with to display and hide pins on a map depending on where we are heading to on our site.
Loading up the homepage displays a map with all our pins. Let's then imagine we click on the /curated/ link. We expect to see the curated pins, but instead both our and the curated pins are displayed because the previous view didn't destroy its state like rendering it on the server would. Let's see how we can fix this:
This is definitely not desirable. We'll quickly duplicate a lot of code as we add more views to our application. How about if we associate each view with a given state that builds and destroys everything that is required? Enter the JavaScript State Machine:
We've eliminated the dupliacte code by replacing it with a state machine that switches states on different views. As we enter new states, we can perform cleanup on the previous state, and build up on the new state. Partial page updates just got a whole lot easier by declaring simple transitions from view to view. Also, we can easily expand on this code by simply adding new states to our state machine.
Unlike on the server, you can't simply rerender the whole page in JavaScript heavy applications when you interact with them. Partial updates to the content are required - and sometimes one partial update will not destroy previous updates that are not of use anymore. Using a state machine can aid you a lot in making this process very easy.
You should now download the app and check out the website to see it all in action.