I am a little confused on this.
If in Rails, with erb files we can build pages layout, 1) in what situations would we use webpacker to add vue.
What i understand so far is a Vue application would at times make a request to the server lets say to populate data. 2) Would that be the only use or are they other uses cases?
Also 3) is it best to generate a vue or angular app as a standalone (like vue create app so vue is in a front end folder and rails in a backend folder) or to use webpacker in rails
I'll try and answer your three questions at once, hope that's ok!
There are three common ways you can integrate Vue.js (or any JavaScript) library into a Rails application:
You can load it through sprockets, which is the built-in Rails asset packaging library. You would do this if your application is mostly going to be statically rendered and NOT a SPA (Single Paged Application). Sprockets is very tightly integrated with Rails, allowing you to refer to assets in your Rails templates and code. However, Sprockets is quite far behind Webpack in terms of the actual bundling/packaging, optimizations, and ease of use for any complex JS project. So you would only want to do this if you're adding a tiny amount of interactivity to a mostly static website.
You can load it through Webpacker. The idea of Webpacker is to give you a really easy way to start building a SPA with a rails backend. So you receive all the benefits of Webpack but don't need to tweek many configurations (at the start), or set up a separate web server, or worry about CORS. It's great for starting a new project/prototyping in or progressively integrating Vue.js into a larger static website. The downside is that Webpacker uses webpacker.yml for its default configuration which adds unnecessary confusion when you will eventually need to have more complex configs.
Finally you can load it through a separate web server ("standalone"), and in the long run, this will give you the greatest degree of freedom through less Webpacker middleware and access to the most updated webpack version. It also offers you the ability to scale, secure, and do fancy stuff like Server Side Rendering. The downside is this does require the most upfront setup and long-term maintenance time. AFAIK this is the most common way companies serve SPAs.
Related
I have surfed a couple of hours through the web but couldn't find any articles/walkthroughs/comparisons touching erb integration of webpacker. I've found 1 question, unfortunately, the author haven't read docs attentively and the answer was right there, so - no any additional info there.
I have seen plenty of articles about vue and react, but nobody says a word about erb. However, it's quite clear why using react/vue/else similiar, it is not with erb.
The theme is quite vast and I expect a little hate towards me, so I'd ask two related questions (but if you have something to tell more about it - that's appreciated).
As I understand - it's vanilla (plain) js (maybe with a flavour of jQuery) caring just about dom and styling, with all the preprocessing made by rails. If it is so why not just continue using sprockets?
And what are the reasons to choose it instead of some react/vue/else framework?
You may use both : a vanilla JS framework (React, Vue ...) and some erb files. I find it interesting to setup my constant and other configuration variables within a .js.erb file that is generated by my Rails app when building the js app.
Things I like to put in this erb files :
schemas of my api, generated by my serializers
constants, like enum
values to be used in forms
To generalize, you can put anything owned by the backend that will not change at run time
this save you a couple API calls to retrieve this data. However, I tend to stop doing this as your JS app and Rails become tightly coupled and you can't use the sources of your JS app outside the Rails app
I'm running Rails 5.0.2 on a project, looking to use react-rails and webpacker to handle things on the front end. I've only got a few components/pages that need to be dynamic, so I'm leveraging server-side rendering for a majority of the pages.
I've got, so far as react-rails is concerned, a pretty standard set up with webpacker. After following the instructions in their readme, I can load a page with CommonJS modules and whatnot.
The problem: Since webpacker is serving up its assets on localhost:8080 and rails is operating on localhost:3000, the session cookie I start in the static half of the site isn't accessible to the dynamic half. I know I can probably solve this with an nginx proxy, but I was wondering if there wasn't an existing fix for this with the aforementioned tools, as this is kind of a game breaker for local dev!
Webpack provides a proxy configuration when using their webpack-dev-server: https://webpack.js.org/configuration/dev-server/#devserver-proxy
This should proxy any request that isn't a static file.
I want to add frameworks like AngularJS, Bootstrap and polymer JS into my rails app. Problem with the gems is they are unstable with new versions and they even stop developing gems(which leads to failing of one gem which depends on another)
So I just want to add those frameworks directly into the application root html file via CDN(offered by the vendor). Is that a good practice? Will it cause any future problems in production environment?
Yes, if you are using reliable CDN's (and those offered my vendors can be treat as one) it may even bring you some improvements in the production enviromnent, e.g.:
those assets will be often already cached on your user's machines
it circumvents browsers limit the number of concurrent connections from the same domain (as your app)
On the flip side, on your dev enviromnent you'll have to wait a liiitle bit more for the website to load those assets comparing it to loading them from localhost ;)
if you dont use CDN,you have much control over the assets ,as they might change/update or sometimes the url can be down :( in worst case scenario..so i suggest using local assets if there is large dependency and for small dependency ...you may use cdn. :)
use this to set up polymer js onlocal.
So that I could take advantage of all the already well developed front-end tools like requirejs, bower and grunt... It's just that so many of them somehow get crippled going with rails.
Primary advantages:
It is easier to load third party scripts this way. It is always possible and sometimes easy to put these through the asset pipeline, but it is also often tedious and you lose bower.
Scripts in public will not be digested, so they can be loaded by non-rails pages easily. For example, you use a javascript file on your site, and also need to load it on another, e.g., PHP site, or need to allow other people to load your script for an embedded API, etc... then you'll need to serve from public.
Primary disadvantages:
Because you're not using the asset pipeline you lose:
Asset combining and compression. Asset pipeline CSS and Javascript will be loaded in a single HTTP request each, and the content can be minified. This makes first page load on your site faster, especially if you have lots of client code or a site that needs to be super snappy for occasional visitors.
Digesting. The asset pipeline protects you 100% from cache vagaries and potentially having different users seeing your site with different version of your assets. Once you deploy, every visitor will get the new assets.
Relatively automatic etagging. Once those visitors get the new assets, their clients will generally cache them for a long time. Rails can afford to let assets cache essentially forever because digesting ensures you're not punished for this later.
So there are pros and const both ways and neither is right or wrong.
It's just that so many of them somehow get crippled going with rails
Pipeline
The reason is you're not meant to use the likes of Grunt etc with Rails. Rails' asset pipeline is only meant to contain the files which can be precompiled & used directly in your application:
The asset pipeline provides a framework to concatenate and minify or
compress JavaScript and CSS assets. It also adds the ability to write
these assets in other languages and pre-processors such as
CoffeeScript, Sass and ERB.
This will typically mean compiled third party JS/CSS files, and your own application JS/CSS files. I don't see how something like Grunt would provide any benefit to this? All it does it create a way for you to manage dependencies, versioning & source of particular assets?
--
Public
Using the files in your public folder isn't such a big deal. One of the most prominent things it does do is to exclude those particular files from the file digest processs, allowing you to use the likes of endpoints (scripts) which can be accessed by other services (outside the scope of routes.rb)
A good example of this is when we created an analytics system, and put the analytics.js into the public folder, so all the widgets could access it. This allowed other sites to access this file, regardless of the state of the asset pre-compilation.
One caveat to this would be you could perhaps have some way to store a "pseudo" file in the public folder, with it routing dynamically (with ERB) to the precompiled equivalent, but I've got no experience with this
--
Pipeline
The benefits of keeping your assets inside the asset pipeline, as stated by gwcoffey, are:
They will be compiled as you design (I.E primarily into application.js, but also into any other files you define too)
You don't need to worry about versioning (every precompile is basically a way to better the version without worrying about grunt etc)
You can include as many dependencies as you want - meaning you're able to create a totally modular set of assets which can be used throughout your app; rather than single scripts which will have their own dependency base
Recommendation
Unless you maintain third-party scripts which need dependencies to run, I would not recommend using Grunt for Rails. If you develop your own JQuery / Javascript scripts, by all means run them through Grunt etc; but for use in your app, I'd steer clear
Hope that helps!
I wanted to try out Angularjs. However, I have been trouble deciding on where I should located my angular app.
I am using Rails framework for the backend. I have seen tutorials where the entire angular app lives under the assets/javascript folder.
I was wondering if instead of living within the assets/javascript folder, I could make it live outside my rails directory entirely. That way, I can potentially separate my backend and front end entirely. (Is this recommended?).
I believe the asset pipeline also precompiles a lot of the assets. If I were to separate out the angularjs asset, would I need to precompile the assets somehow?
Thanks
I've been working through a similar set of questions. There are some good tools that allow you to integrate AngularJS directly into your rails asset pipeline, and they to me look good if you want just a little bit of Angular.
However, if you want a full Angular front-end, aka a single page web app, I think you'll eventually be limited by compatibility and some of the tooling. I feel like the Rails gems won't quite keep up with Angular, and so you'll be into version conflicts. I've also seen more and more tooling for Angular as a standalone, and I very much like the ng-boilerplate project template. I also like much of the testing tooling such as karma, and I haven't really sorted out a way to integrate karma with rails.
For that reason, I eventually decided that I'd keep the two separate. Initially, I did that through creating a rails application and a separate angular application (separate directories). I used ng-boilerplate as the framework for the angular end. I wrote a tutorial on that. This eventually got a bit frustrating, and I wrote some more thoughts on it, the main annoyance was that I had two git repositories and it was annoying to keep them in synch. It's also sort of annoying working with an IDE across two directories. I've ended up shifting to rails and angular being in the same folder, and they seem to play nice, as each uses different directories within that project.
In this current structure, I'm using the grunt setup that came with ng-boilerplate to minify all the code, package it and also run karma unit testing. I haven't yet nailed the end-to-end testing, but it's on my list. I've found this to be a relatively productive work environment. My chosen structure for my pages, controllers and karma test cases has some repeated code (I'm choosing not to factor it out to maintain readability). I'm planning to extend the rails scaffold generator to create the javascript framework for me - so when I create a persons rails scaffold, it will also create a persons angularjs scaffold for me. I'll update here if and when I do that work.
EDIT: I've completed the scaffolding work as well, which allows rails to automatically generate the angularJS elements when you generate the rails models/controllers etc. The blog post is here: http://technpol.wordpress.com/2013/09/24/rails-generator-to-generate-angular-views/
You could use a grunt based workflow:
How to manage AngularJS workflow with lots of script files
http://newtriks.com/2013/06/11/automating-angularjs-with-yeoman-grunt-and-bower/
If you start with a decoupled frontend, use mocks at first so you can stay within angular and not lose focus switching between backend and frontend logic. An advantage of building a single page application is that you can develop it independently of the backend api. See (http://docs.angularjs.org/api/ngMockE2E.$httpBackend) for information about mocking http responses.
We have been using AngularJS with our Rails application, in a way where we have been using Rails ERB templates, but switch over to using ng directive as and when required.
For this above setup we have used bower/bower-rails gem, which lets us use bower to manage the angular packages and their dependencies. We commit this into our repo, in the javascripts directory, and is taken care of by the Rails asset pipeline.
This setup has worked well for us considering we have above 50-50 % split of our views between the ERB templates and Angularjs.
More about this setup in the links below:
http://angular-rails.com/bootstrap.html
http://pete-hamilton.co.uk/2013/07/13/angularjs-and-rails-with-bower/
http://start.jcolemorrison.com/setting-up-an-angularjs-and-rails-4-1-project/
There are many advantages of separating out your api service (rails in this case) and your frontend components. As we do for ios/android apps, angular client can live on its own as a separate entity. It will be a static website that can be deployed on s3 or any static website host. It just needs to communicate with your api service. You could setup CORS to make it possible.
Some advantages of this workflow
You could use rails-api, which is a subset of rails application. If you are just going to use rails to build apis, it doesnt make sense to have all functionality that a complete rails app provides. Its lightweight, faster and inclined more towards building API first arch than a MVC arch.
You could use yeoman angular-generator to generate an angular app and make the most of grunt & bower to manage build (concat,uglify,cdnify etc) and dependencies (angular modules).
Deployments will become flexible. You won't need to depend on one to push the other.
If you ever plan to change your backend stack (eg rails to play/revel), you would not need to worry about your client components.
By splitting the development of the frontend and the Rails backend you could distribute the work over two development teams and keep the application as a whole very extensible.
There is also one downside to this approach.
By having the applications in two separate repositories, you can’t easily have a full integration test. So you will have to test the apps separately. You could mock your apis to test angular app.
We have been using this approach and would recommend others the same.
Less dependency & more productivity.