I’ll have my effects on the side, please

This one’s about side effects.  I’ve been trying to do some reading on functional programming lately.  It seems really cool- though a lot of it is still over my head.  It seems like the fundamental tenet is the elimination of side effects.  A function should do one thing, and do that one thing every time it’s called.  If it adds two numbers together, it does that, then returns the sum.  It doesn’t add them together, drop down a menu item, update the state of your app, and then return the sum.

The idea is great, if a bit lofty for web development, where side effects are sometimes a necessity.  But the underlying principle of avoiding side effects is a good lesson.

So we launched the new website, and it seems fine.  But as with anything this large, there are bugs.  We fix them as they’re noticed, but one we didn’t even consider has to do with the main menu and Angular views.

To view a certain product, you click the link and Angular routes you to a new view.  All well and good.  But all other content from that page also sticks around- some of it not really necessary- and could be confusing.  So a co-worker had the idea to simply hide some sections (with a combination of ng-show and ng-if) when viewing a product route.

Works great- the view pops up quick (no reloads- thanks Angular!) and the non-pertinent info is hidden.  But there’s something we didn’t think of: the main menu.  It’s at the top of the screen- with links to all sections of the page, some of which are now completely unavailable.  Click one of those, and nothing happens.  Probably not a huge issue, but one that should be resolved.

So, I started writing a simple function on the main scope to show a hidden section if that menu item is clicked.  Simple enough.  But yet another side effect crops up: the footer.  It uses a different controller, so now I have to create a service to share state between the footer controller and main controller.

Eventually, I got it working, though services/factories in Angular still give me the run around.  It’s simple enough when they’re just used to provide data, but when you need to change that data, then share it between states, it gets a bit complicated.  Though it was a good day of trying different design patterns.  I finally settled on the ‘private variables’ option: initialize an object with a couple boolean vars in the service, then return the methods used to update and check those variables.

Works like a charm, but it does make the whole functional programming thing look pretty nice.  My last 2 weeks of work have been devoted to fixing issues created by side effects.  Also, on a side note, for the Angular masters out there- is there really a downside to using rootScope?  That was my first solution for sharing state between the footer and main controllers and it worked like a charm.  But everything I’ve read says this is a bad idea (though no one says why), so I spent a few extra hours working out how to do it with services.  Either way seems to work just as well, but I’m sure I’m missing something.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s