say ‘hiya’ to our new front end process

Following on from Jonathan’s post about our new listings widgets I’m going to cover our updated front end development and deployment process.

thought and file structures

At the highest level we decided it would be best to have individual projects in their own git repositories. This way we can independently develop, build and deploy without worrying about version and merge issues. We also realised we would need a single entry to all the embeddable widgets, so we decided a loader that accepts configuration for all widgets and modules was the way to go – a client includes load.js, initialises with a JS object and as if like magic all dependencies and files are loaded.

We use the term widgets for the top level containers (EPG) and modules for the sub grouping of functionality (grid, featured and search). Obviously maintainability is important, so all JS files are small independent files. Therefore modules are a single master file (grid.js, featured.js and search.js) and, depending on the size of the module, multiple component files (grid/http.js, grid/queue.js, grid/events.js etc.). For the CSS we have a base file that includes resets and basic layout styles, widget files that contain all special widget and module styles and finally skin files for our vanilla development skin and client skins.

It’s worth noting that all the JS and CSS is namespaced to avoid conflicts with host page styles and functionality, we don’t want to mess with someone’s hard crafted site.

tools

Both JS and CSS are separate files in structured folders during development and then concatenated and minified for release. We decided that, for this and future projects, these tasks should be done during deployment, as such Adam and myself had many hours talking about repository managements, tagging strategies, file structures and config layouts. The end result, thanks to Adam’s hard work, is a reliable and fairly robust deployment process that he’ll talk about in the future!

Before getting to deployment though, it’s important for our code to be of a high standard, and to follow style guidelines. So while developing locally I have CodeKit by incident57 running in the background, JSHinting my code and pulling me up on mistakes.

For full experience testing I like to have my development page load as close to the production release as possible, therefore I use load.js to load a development grid.js, featured.js and search.js. But didn’t you say all your development files are separate? I did, that’s why I use CodeKit to check and concatenate (but not minify) all module files together on save. This forces me to fix any mistakes before I can view changes in the browser, forcing me to write better code first time!

That’s a brief introduction to how we’ve started thinking about and implementing our new widgets. With the EPG widget being the testbed for our new front end development methods future iterations will hopefully help us learn and improve even more! I’ll go in to more details about how we load modules (load.js and its configuration) soon, so stay tuned!

blog comments powered by Disqus