Architectural Toolkit that unifies most of the common libraries used nowadays to simplify project setup and code development in general.
If the following technology stack is your choice or you just simple love developing web-apps using these libraries, please checkout this project.
While I personally consider it experimental, because most of the logic implemented and the internal mechanisms to solve dependency injection need to be tested directly in the field with real web-apps, the usage of this package is optional either, if your decide to use it to wire all the pieces completely or partially.
Also, this IoC package was inspired by the module
wire.js of CujoJS Project. It essentially establishes a good architectural foundation for your project and keeps the separation of concerns as clean as possible. So, you will find some similarities while declaring specs using Boneyard.
Lastly, Boneyard provides 2 more additional packages,
Boneyard UI package offers a list of common reusable components, easy to extend and easy customize. These components are in essence, "classes" that extend the original
Backbone.View to get the best of backbone's binding mechanisms, plus all the styling capabilities provided by bootstrap to skin and render those components.
Boneyard Util package, provides a set of utilities that may help you to perform some common tasks.
Boneyard was empirically crafted by following common good practices discovered while developing web apps using backbone/requirejs libraries. However, boneyard is still not recommended to be ran in production environments but for experimental purposes only, due to the fact that the patterns and decisions that made up this toolbox are going to be subjected to change over time. As long as the community will provide feedback based on their experiences using this toolkit to keep improving the original idea until the tool itself will reach a certain level of maturity to consider it production ready. Be aware of possible bugs or missing functionality, specially in the bootstrap-ui module. I will be fixing those as soon as I can.
The library itself is distributed on bower. So, to get the distribution you run:
bower install boneyard
However, Boneyard also ships with an optional tool called Boneyard Composer that is only published on the NPM registry (See 'Usage' section below). This tool is a simple utility that in general you will run only in development mode. In your project root folder, you simply run:
npm install --save-dev boneyard
If you've decided to give Boneyard Composer a shot, this tool may help you with the development process.
Boneyard Composer, is a simple command line tool that allows you to test your modules/components code in real time. Just by using a config json file, it will generate a temporal folder and spin up a server to serve all your source code so you can access it within a browser to check the results.
Also, the server will be listening for code changes (whenever the source code changes, the browser will reload automatically). This should be very useful, especially while building spec configurations file from the Boneyard IoC package. It can be a tool to consider inside the development process to integrate it with Unit Test frameworks, less/sass based themes development, HTML template packages compilation and so on.
Please, visit the documentation related to the usage of this tool.
If you want to provide feedback, suggest changes or simply check the source code, here are some quick notes and steps after pulling the code from master.
npm install -g karma-cli
npm install -g bower
npm install(step 3)
make composeryou will have access to hit
You will probably notice that even though I decided to ship Boneyard with a boneyard-ui package (Simple Backbone.View "classes" that spits out some html chunks, in combination with some bootstrap css styling rules and a basic api, I'm definitely not a big fan of the DOM implementation and the HTML declarative format at all as a creational pattern.
With that being said and along with the development of this library, I found completely difficult (and annoying) for the sake of a good development process, to let a declarative format resolve the concept of child > parent relationship structures of a web app
<div><dom-tell-the-browser-to-create-a-combobox-inside-this-div></div>, when in fact this level
of details makes different moving parts very hard to keep track. De-structuring probably was one of the major goals on this project, by providing techniques on how a developer can efficiently wire or establish structural relationships between elements.
I strongly believe that the web development experience could be a more enjoyable place.
Copyright (c) 2015 Patricio Ferreira
Licensed under the MIT License