This is a must-answer question that needs answered for a generation of coders.
I know to go to the website, but how do you actually download Backbone and start coding.
Most tutorials leave out this stage.
Thanks for helping!
Most Backbone code I see on stackoverflow is a real mess lacking structure which is a shame. But the flexibility in the right hands is also a very strong point that is why larger companies still use frequently choose Backbone whilst newbies would go for something with a little more magic out the box like Angular or Ember.
This is what I recommend in a general sense:
Grunt or gulp for tasks - grunt might be easier as it is more widely used still. Main tasks would be:
- build (compile and minify your code and css) and bundle into a build folder
- server (runs local server or a server from a build folder)
- test (if you have unit or functional tests)
Next you have an index.html file which contains an app wrapper and a single RequireJS call the the entry point of your code.
My folder structure would look something like this:
server/
server/server.js
public/
public/app/app.js
public/app/modules/
public/app/extensions/
public/assets/
public/assets/css/
public/assets/images/
public/packages/
public/index.html
dist/
dist/<env>/public/assets/
dist/<env>/public/app/app.min.js (or app.js depending on env)
package.json
Gruntfile.js
A colleague's boilerplate is probably the closest to my ideal setup in the public domain: https://github.com/mderrick/backbone-boilerplate
There is also marionette: http://marionettejs.com/
Related
So I have an existing Create React Application and I want to be able to build a chrome extension to work in conjunction with it. Is there a away I can use webpack or something so that my extension kind "lives in" the React application? I want to do this because the existing application is quite large and I don't want to have to make changes (UI, api, or otherwise) twice. In my head I'm picturing it something like this:
- MyApplication/
- src/
- index.html
- App.tsx
- components/
- <bunch of other useful stuff>
- extension/
- index.html
- Extension.tsx (equivalent of App.tsx in react app)
Basically I'd be able to import whatever I need into the extension and run some command like build extension and it would bundle just the files and dependencies imported and necessary for the extension and output that to some directory I can upload to the Chrome Web Store.
I also briefly considered splitting the application into into something like MyApplication-core, MyApplication-web, and MyApplication-extension or something and just installing core in both web and extension but not sure if that's the best strategy or not. The first strategy I outlined seems simpler to maintain but I could be wrong.
Also, if there is another strategy I haven't thought of please let me know! Happy to add clarification if necessary as well! TIA!
Just build it and add manifest with required configurations. After this you will have posibility to load it as an extension.
I'm building a React app with webpack. I was curious about where to put my "public" folder. I know in create-react-apps, the public folder is outside the "src" folder.
I'm not sure I'm clear on why you would want your public assets outside of your source folder. Is index.html not part of src? Is that not a crucial part of your code? Why would you put the public folder outside on it's own?
I'm trying to find good reading on this topic, but it seems folder structures are very subjective. If anyone could explain this, I would appreciate it. I want to firmly understand why the public folder is outside the src folder in create-react-app.
You posted this quite a number of months ago and I am surprised that there have been no responses as you raise an interesting point.
I believe the answer to be somewhat historic. In the past, the public folder was, indeed, public, meaning it contained a well-structured and hand-crafted index.html file and perhaps some other artifacts. These were intended to be consumed "as-is" while other parts of the application (i.e., JavaScript) remained in their own folder to be transpiled, merged, etc.
But that was then and this is now.
With the advent of modern packaging/bundling tools (webpack, brunch, parcel, and so on), such a distinction is no longer relevant nor does anyone really give it much thought.
With these bundling tools, everything is "source code" (as you pointed out) with the tools transforming index.html to correctly reference bundled CSS and JavaScript code.
So, while I cannot speak directly for the create-react-app team, I would submit that the public folder concept is largely an anachronism harkening back to the days where it really was public.
These days, everything ends up in a dist folder, which is then served to the end user. The machinery that creates this dist folder is largely ambivalent on how you structured the tool's input to arrive at the final distribution. Basically, the tools do not care about a public/src folder distinction, so why should you?
I hope that helps. I personally have index.html right alongside index.js in the src folder. The process is src -> bundler -> dist (just like good old C programming: src -> compiler -> exe).
I am using webpack in my Project, here is the tools:
HTML as - jade-html-loader
CSS as - sass-loader
Project written with AngularJS - all with components & templateUrl (ngTemplate-loader in webpack)
So I got 1 JS file in the end of the process.
All this stuff pretty cool, but I think that it will be good to create static HTML files for clients...
It's going to Improve performance(caching / no need to draw DOM elements throw JS) and it's better for browser - to download few small files, not one big JS...
I am wrong? I can't find good tools that generates static assets(html, css)/cache files.
In the end of the line - I need to find an easy way to require Jade files as templates(templateUrl) into Angular Component, but files needs to be static - so I can see them in "Sources" of the browser...
It is hard to explain - so I hope you can understand me =(.
I been there and what i learned is angular cache template are faster then static. You can also copy static html files to dist map using npm cpy tool but i will highly recommend you to use angular cache template. There is this tool you can use for converting you jade to html.
You don't need to build only one single file you could build one for the vendors and one for your app this will keep your app more clean and you can also make one for the only templates which load in angular from cache on demand. I hope i could explain. webpack come with lot's awesome plugins witch can make life easier! good luck
After week I agree that cache templates works fantastic! =).
I used plugin "webpack.optimize.CommonsChunkPlugin" to generate 2 files for my app:
Vendor - all node_modules/bower_components/libs (js+css).
App - all source of app - controllers/models/business logic/views (js,css(sass),html(jade+ngTemplate for angular)).
My entry looks like:
entry: {
app: './src/app.js',
vendor: [
"angular",
"angular-route",
... and other libs...
],
},
And there I found really cool thing: html-webpack-plugin - this plugin creates index.html file and automatically attaches all your generated JS files.
Add Used "hash" string to my files.
My dist looks like this:
/dist
/index.html
/app.xxxxxxxxx.js
/vendor.xxxxxxxxxx.js
Little magic with webpack.optimize.UglifyJsPlugin to minify all files.
And now I got lightweight, small app that waiting for deploy! =)
There are several blog posts that explain why switching from grunt or gulp to building with just plain npm is a good idea for example this one by Cory Hourse or this one by Keith Cirkle. One thing these blog posts do not explain is how I can easily do environment configuration. For example a common requirement is to have different REST API locations. During development the server might be running on localhost:8080, but on production it should be accessed through a relative URL such as /api or /rest/api and the port or protocol are different for development and production.
There are several solutions for this. For example grunt supports template strings like <% %> and <%= %> and there are grunt or gulp plugins like in this question about grunt-ng-config. These solutions are specific to Angular (which I am using), but I am not necessary looking for an AngularJS specific solution.
I also know of the angular-environment plugin, but as far as I can see this does configuration at run time and I am looking for something that can do this at build time.
So what I am looking for is something that allows me to configure my application at build time either by replacing some template strings or by generating a Javascript file with some variables that I can read at run time.
One requirement is that it should be OS independent. So I do not want to use UNIX specific tools such as sed to rewrite a file. And due to different variable expansion (e.g. % vs. $) a solution should not rely on environment variables.
Is there an existing solution or a best-practice for this?
due to different variable expansion (e.g. % vs. $) a solution should
not rely on environment variables
this cuts off your best solution. Why not rely on env vars? node provides
process.env
to access env vars. You could create custom gulp / grunt tasks that use process.env instead of the "different variable expansions" you refer to.
You can use, for example, Jade templating to pass env var values to your HTML at build time. This would generate your index.html on the fly as part of the build process and add relevant classes based on env vars.
For example, according to the value of an env var you might set a class on the HTML tag.
This might reflect the customer.
Then you could have some CSS
.customer1 .myimage {
background-image: url("customer1.png");
}
.customer2 .myimage {
background-image: url("customer2.png");
}
or you could use JavaScript to detect which class was added to head during the build.
Using gulpjs and bower, Id like to start with the bower.json file to call on what package dependencies I want (ideally start the build with html 5 boilerplate, then backbone). Since the whole point of using gulp is for easy project management I would like to understand how to auto insert the scripts in to my project (pulling from the bower_components dir) and add the path to my head tags, I assume this is a responsibility gulp should be handling, in the link below I am under the impression grunt does provide this functionality, so if grunt can gulp should be able to.
This tut seems to cover everything I am looking for, except it is using gruntjs with the plugin "grunt-bowercopy" http://simonsmith.io/managing-bower-components-with-grunt/
So does anyone know how to get gulp and bower to play nicely. It would be cool to download the html 5 boilerplate, then for my javascript include backbone/jquery as well as some css like fontawesome and such with one command bower update, and have it insert the script tags in my header, and pull the main files I need into my project (this would kill a lot of tedious work). I assume grunt does handle this specifically with the "grunt-bowercopy" plugin, so essentially I am looking for a plugin "gulp-bowercopy" or something that provides this?
I still have a lot to learn about gulp/grunt and how to really leverage them, but this seems like an awesome tool to have.
essentially I am looking for a plugin "gulp-bowercopy" or something that provides this
You should then consider looking into either:
gulp-bower
or gulp-bower-files
as they likely provide the same functionality as grunt-bowercopy.
You can just use wiredep directly like the gulp Yeoman generator does. Here's a code sample from the gulpfile.js.
var wiredep = require('wiredep').stream;
gulp.task('wiredep', function () {
gulp.src('app/styles/*.scss')
.pipe(wiredep({
directory: 'app/bower_components',
ignorePath: 'app/bower_components/'
}))
.pipe(gulp.dest('app/styles'));
gulp.src('app/*.html')
.pipe(wiredep({
directory: 'app/bower_components',
ignorePath: 'app/'
}))
.pipe(gulp.dest('app'));
});