Ruby on Rails
Completed the official RoR tutorial. I like the framework so far. It seems very powerful. It packs a lot of functionality without having to write much code, and the structure it forces on you makes it seem like it can be quite simple to write quite complicated apps. It reminds me a little of Django also, the way it is opinionated and structured as an MVC framework.
This gives a separation of JS and HTML. The HTML communicates to the JS via these data attributes. The data attributes make ajax calls. In our Js and files we intercept these AJAX calls, e.g. via
$(“a[data-remote]”).on “ajax:success”, (e, data, status, xhr) -> alert “submitted”
According to their description this Unobtrusive scripting adapter for jQuery has these function:
- force confirmation dialogs for various actions;
- make non-GET requests from hyperlinks;
- make forms or hyperlinks submit data asynchronously with Ajax;
- have submit buttons become automatically disabled on form submit to prevent double-clicking.
React and Rails
This guy talks about 3 ways to integrate React with Rails, including the pros and cons of each way. These 3 ways are:
- BUild 3 separate apps. A Rails App which functions as the API backend, and a node/React app which works as the front end. Apparenlty this can be cumbersome as you need to maintain two separate apps, and lose out on some of the advantages you would get by having a single app.
The standard Document Object Model, takes a HTML file and turns it into a DOM, where each of the elements become a node in this DOM, and the entire thing has a tree structure. The DOM is an abstraction of the HTML text.
This is great for traversing all the elements in a DOM, but does not do it so quickly.
For example imagine the call var item = document.getElementById(‘item’). To get this it would have to go through all of the nodes in the DOM.
React used the virtual DOM which creates a sort of abstraction of the DOM. In the virutal DOM the nodes are made up of React Elements, and these are stateless. The React Elements are generated by the rendering of React Components. The React components are stateful, and whenever they change on the React Elements referring to them is updated. And finding those Elements is easier than traversing the whole DOM, which gives the virtual DOM performance advantages.
Ok, so evert HTTP request and reponse contains a header.
For requests, tt is in the Header where you put the type of request, e.g Get/Post/Head/Put/Delete.
The request header also contains other information such as browser type, last modified parameters, OS type, e.t.c
We can post data to the server using a post request, and it will appear in the first GET url parameter, with the data appended to the URL. However the amount of data we can put here is limited.
When we send data with a POST request, the data goes in the ‘content’ section and we can fit much more information there.
Also the url in the request is only listed as a suburl, with the main domain not being mentioned. I think that is how cross domain requests are detected, because we are making a request to another domain, and that is specfied in the header.
A HTTP response is what the server sends based on the request. Different info can also be contained in the response header, such as the data type it is sending, the time the file was last modified, and server information.