I have some background questions, because the more I think about it, the more confused I get.
What I want to make is a very simple reviewsite where people can leave a review/comment with a rating (no signin function). The frontend will have to be in React and it will also need an average rating component.
So far I set up a rails API and in the model I included a title, description and rating. But I'm thinking that it might be better to make a separate model for the ratings?? I'm not sure when it's better to create a separate model.
My second questions is; How would I test a React component using Rspec? Would I need a gem for that?? I don't understand how that even works when the Rspec file is in the Rails API, and you want to test a component inside the React app...
Maybe someone could explain this or send me a good link where I can find this information?? Of course I tried google, but it just left me even more confused.
Actually you can't build a SPA application just by using React. React is not a framework it's a library so you have to include React into a framework like AngularJS. Then, you can't test React or AngularJS with Rspec because Rspec is not meant for UI testing. You should use something like Protractor. Also, I recommend you look at Grape API to build the service layer of your application. Finally you should add a separate model for ratings if you build the application on a RDBMS because there could number of ratings. Otherwise for something like mongodb you can embed the ratings into the post table.
Related
I know there is a lot of similar information out there, but I couldn't find anything specific to my use-case...
I'm on rails 5.2 using webpack and react is installed (and functioning). I'm trying to update a semi-complicated filter page I have, which functions as a very large multi-select checkbox filter (using form_for with remote=true). When the user checks a box, an AJAX call is made to rails and new data is displayed. The form is created dynamically based on data in my postgres db.
I have a basic react filter component already created using static data and it is updating my state fine (still working on creating the actual query). I just need some direction with the BEST (as in 'the most correct that you would do for the company you work for even if it is more complex and takes more time') way to pass in data to my react component and render it with the dynamic data.
I've seen main types of ways to do this. The first (which seems like a terrible idea) is to render a dummy div element with data attributes and then read that into the react component. The second is to 'do it in the controller' or 'use an api'. Does this mean setting up your rails project with an api endpoint and calling it via the react component? Does it mean using your existing controller routes and making the call that way?
edit: I've also seen several gems being used like webpacker-react, react_on_rails
I ended up going the API route. However, with Rails server-side rendering, I was getting two get requests, once via HTML and when the component mounted and made the API call, once again. I ended up switching the entire front-end to React because of this...
There must be an easier way to work this...
I have started a new project in which I would like to use React and Rails. This project is on the small side and will require some basic interactive UI, hence React. As far as I know there are two ways I could get started with this:
Using the react-rails gem and use the built in view helper
Create a Rails API and React/Flux frontend app
I have a few questions however. In no particular order:
React-rails seems like the simpler solution, but what drawbacks would I be facing?
I come from a Rails and Ember background so the Rails API + React FE solution makes architectural sense to me. But with the react-rails gem I'm confused on how some things should be done. Primarily, how do I handle routing? I suppose I won't have access to any react route helpers and will need to pass paths into the react components as props?
Thanks in advance!
For a small project React-Rails, https://github.com/reactjs/react-rails, is great I have used it in production the last year on 2 sites that get about hundred thousand visitors a month and I haven't had any issues.
That said if you want to use Redux, React-Router or Flux don't use React-Rails go the API route.
My rule is if you are just using React components then use React-Rails.
If you are doing a Redux, Flux app then just make a frontend app.
It depends on how much your server is doing and also your team. If you have a lot of business logic that you want to keep in Rails, then you may want to have that logic running on a dedicated Rails server and expose as APIs.
You can then have a NodeJS server that does nothing but fetch data from APIs and render React to send to the users. The only interaction between react and rails is via the APIs as JSON. This basic setup will scale really well and is a pretty simple mental model.
If the project gets bigger, this means you can have JS-only devs work in JS only and Rails devs work in Rails only. Plus if you want to move away from Rails or React later, there's no added complexity there.
OR
If all your devs are React+Rails and the project is a bit small for multiple servers, then I think using react-rails to serve up your pages is a fine solution.
I'm goint to create a RESTfull service app is made of Rails5 with API mode.
I also need an admin app that provides web views for managing users and contents.
These two apps will share codes each other.
I know a way of creating the API mode app.
$ rails new apiapp --api
How do I create the other project?
The way I would implement this kind of functionality is like so:
RAIL API for your model, database, validation and relationships logic.
Client side MVC for Admin app with RESTful calls. For this I would use Backbone Marionette.
this is the cleanest, least code repetition implementation I can think of, which follows industry standards.
this is as per the software mantra 'consume your own dog food' - if you create an api, use its interface to do your stuff. this way you test and improve it as you go.
If you want RAILS only on both ends, you would be better off implementing your ADMIN and your API as one app, for least code repetition. Create an API controller name space for all your exterior calls, and code normal rails for your admin views and stuff. this way your database and model validation and relationship logic is shared, but controllers and route namespaces are not.
Toodles.
You build the other project as a normal rails project. The thing to understand about Rails 5 api mode is that you cannot have normal html stuff as part of it. The entire rendering pipeline (assets and such) is missing. Rails 5 api mode is fast because big parts of the environment are just plain gone.
What you want to do is have 2 projects:
admin
api
And figure out a way to share your model logic across them.
If you use devise for authentication this is particularly tricky since devise adds things into your user model that you cannot have in an api project. Here's how I got around it:
If Rails.application.class.parent_name == "admin"
# devise crap goes here
end
How exactly you easily share a directory of models across 2 git repos? I have no good answer. I have a rake task which sync's things manually by copying them from the canonical source to the destination but that's a hack.
I'm about to start a new project and I am unsure if using AngularJS for my front end would be a good idea not. I've read about people saying this isn't the smartest way of doing a project. And even if I did, Is there a way to get AngularJS to interact with the controllers? This question may be redundant but I am actually curious of how to effectively do this without it being a waste of time.
I've never completely done it, but I believe the way to go is to build a Rails api and then have a separate Angular project use said api. The api could also be used to build a mobile app. I think the Angular project would still need to be served from a Node.js server in production, but I don't think that would be a big deal.
This is what I used to learn how to build a Rails api: http://apionrails.icalialabs.com/book/chapter_one
You can do it within an existing project and share the models from it.
There are several different approaches to accomplish that. I tried about 5 different guides out there, the best I found (and I finally sticked to) was https://thinkster.io/angular-rails - This guide should help you build a basic CRUD app with angular connected to rails.
You use Rails as an JSON RESTful API which responds to Ajax-Requests (Get, Post, Put, Delete). Angular will handle the frontend stuff - sending those Ajax requests to the routes/methods defined in your rails controllers. So yes, of course your AngularJS app can interact with your rails controllers.
This also helped me to understand the setup in the beginning: Instead of the Rails View, you will be using AngularJS as your view:
I really love using angular with rails, because setting up the JSON responses (especially with Active Model Serializer Gem) is very easy and quickly done. i deffinitely can recommend it, and I have not encountered any unsolvable problems - so far.
Just go trough this guide I linked and you will see if this setup fits your needs.
The short answer is that your Rails application will have to present some kind of a public API for your AngularJS application to consume. Angular (and it's brethren, like React and Ember) runs client-side, on the browser, and it needs "something" to make AJAX calls against. That "something", i.e. your backend, can be Firebase, Parse, AWS Lambdas, Rails API, etc. Since you already have a Rails application, it probably makes the most sense to add some RESTful API endpoints that use the existing models (and possibly controllers) to consume/produce JSON payloads from/for the client.
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.