Client request JSON through JS and populate Rails view - javascript

I want that my user(through his browser) make a request to an API(that returns JSON) and that the result populate a view in my Rails(4.2) app. I don't want my app making the requests, only the user.
That behaviour will happen quite often so I am looking for a better solution than Jquery + inserting directly on HTML.
Maybe one template engine would help, was trying Handlebars(tilt+tilt-handlebars) but without success.
To make it easy, what would be the best way to do this ?
Should be:
easy to get data from API, with Jquery or not. Or at least easy to insert the data in the template
easy way to work with the data as Handlebars "each" {{#each objects}} {{/#each}}
easy to insert data into html if not able to do it through the template engine
work with Rails

Look like you are talking about Angular.
There is a lot of resources for this combination link
I suggest Yeoman for scaffolding your app.

Related

How to architect a single page, API-consuming app using NodeJS

I need to build a single-page JavaScript web app that, on regular intervals, pulls data from a couple of public and maybe a few private APIs, and present & refresh the data in different tables. I could build it purely as front-end code with jQuery and just use AJAX calls, but to keep the keys and everything for the APIs private, I need the logic that retrieves the API data to live in backend code (on the same server).
I'm new to building this kind of application, and wondering how to achieve this with NodeJS. After searching and looking at some tutorials, the only way I can wrap my head around it so far is to have an index.html that displays the view with the empty tables, then on a setInterval, have a local JavaScript function do an AJAX call to a NodeJS (Express) route that handles all the API stuff and returns a JSON object in the response. On success, the local JavaScript can write the results to the html for the various tables/divs.
That sounds OK to me, but since all of this will have to live on the same server, it seems really weird to have a front-end script do manual calls to that same server via a URL/route.
What am I conceptually missing? Do I need to employ a master Express layout and use partials for the divs/tables and have the Node backend process the front-end that way? Or should I stick to building .html and .js outside of Express and maybe use something like Angular to create a more intuitive front-end piece? I'm not sure how either of these scenarios would be put together, I'm just feeling around for a better approach.
Posting as Community Wiki answer, as this got answered in comments:
The way I would approach this is with an Angular app. Exactly as you state you would have an API that is built on nodeJS (a bunch of defined routes that grab data and return JSON), and then your front-end angular app. Correct, every set interval your app would call the endpoints you defined in your API, and then update $scope variables based on the JSON response. Your HTML would actually be updated in real time automatically (since that's how angular works with binding models and templates/partials). I would look into angular - sounds like a perfect solution!
Also, once you understand how the binding of angular works, you will never want to write jQuery html() append() or any of those DOM manipulation functions again.

Should I send raw data or Html as an Ajax response?

I have a site written in Asp.net webforms. It uses ajax heavily.
Most forms on the site are submited with javascript. Javascript validates the input and sends it to /ajax.ashx on the server. The server processes the request and sends back a JSON response. My javascript uses the JSON to create html, which it inserts into the Dom.
I'm making a new version of my website written using asp.net MVC3. I've been looking at tutorials on this subject, and some of them recommend doing ajax in a different way. Rather than sending data and then building + inserting html with javascript, they create html at the server, and use javascript only to insert it into the Dom. For instance, in this tutorial.
Which way should I use? Using the new method will be quicker, but is it better?
That's a subjective question. Both approaches are possible and there is no better way. There are pros and cons of each approach.
Building the HTML on the server is easier and will require you less efforts but consumes more bandwidth compared to the first approach.
If you decide to go the first way you could use some client side templating framework which might help you simplify the generation of DOM elements on the client.
Creating html code directly into the server and injecting it with an ajax call is very fast and simple, the real problem is that in that way your service is bound to be used with that specific application. By sending RAW data you allow any app to use that data in any way, without bounding it to a specific application.
returning json feels more flexible to me; you can change what happens with your json response, like the layout it results in. If you return html you return data mixed with layout. This doesn't feel right to me.
I believe it is better to separate the layout from the actual data. That is why you should pass data between your scripts and not HTML.
If you go about it sending HTML, consider that you would have to build valid HTML and CSS, which might not sound hard at first but then you'll start using CSS that is not loaded in the file calling the ajax, etc.
Always separate content (data) from layout. That's why there is HTML and CSS, to separate layout from data. So why mess things up by mingling HTML between data?
Building the html serverside will probably be faster and not bog down the client which is important. Rendering data into HTML with javascript takes time and not every browser is fast with js (i.e. older versions of IE) so things can slow down if you're doing a lot of this.
Like previous posters said, it's kinda subjective because it depends on how much you're offloading to the client. I'm of the opinion that if you can do things serverside, you should.
If you are going to be using this service to return JSON to other applications/clients, then it's probably a good idea to just leave it as JSON and let the client do what it needs on their side.

Backbone js confusion

I have heard a lot about backbone.js and quite frankly I don't understand its concept. Does it require that all the elements should be in single page to work out with its animations and effects ? Or it can grab items from server and load it with transition or i mean different pages but make look like a single page. I didn't understand its concept well, so that's why i am asking. What i am looking for is to combine backbone or any other javascript framework to work with a rails project, that could give some ease transition across pages and can give native application look.
Backbone is also here to give you structure by being MVC, and it allows to communicate in a really simple way with the server. You'll be able to update / fetch / save your data (your rails models for example) on the server. So you'll need it if you want your user to work on an Ajax page without having to reload the page.
For example, you'll fetch all your data from the server when the page loads and then you'll have access to all attributes of your models and will be able to modify it and save it to the server.
Moreover, if you want your models to appear with transition, as Backbone is MVC, you'll be able to make that easily. As you have to choose when and where your views will appear on the DOM, you'll be able to put transition at that time.
By the way, Backbone works really great with Rails!
Backbone.js is all about data to be used in some way from your users, think about it as ActiveRecord plus Sinatra (or rails) on a browser, infact, the framework will give you a way to handle your data inside a browser instead of the server.
If you are looking for a simple way to add transitions to your existing app/website you could use a jquery plugin like Pagify (it rely on $.getHtml()) modifying it to get a fragment of the subpages like my (buggy) fork.

Javascript AJAX API generation for Django

I have a Django page that uses AJAX in some places to enhance the page. Currently the backend for these AJAX calls are normal Django views that return JSON and the URLs to these views are hardcoded in Django.
I'm currently looking for different, nicer way to solve this. My idea is the following: Have some "magic" that takes Python code within Django and exposes a API for it. Additionally, a JS file is generated that can be included into the page that exposes this API to Javascript. Ideally all underlying work is hidden. Is there a project that does this? Or are there alternative ways to do this?
There are many modules designed for API-building, but I don't think any of those (Django REST Framework, Piston, Tastypie) fits your needs.
What maybe is something that is similar to your description is the Dajax Project - it has some automatic ajax registration stuff.

Lightweight frameworks for client-side MVC in javascript?

I'm building a simple client-side survey tool. Users create and edit short surveys and export them as XML (or something similar) when they're done.
I started off using jquery, but realized that it was going to be a headache to map back and forth between the HTML DOM and the underlying XML. It's easy to edit one or the other, but keeping them in sync is a pain.
Anyway, this seems like a standard MVC problem, with a few extra wrinkles:
I want to do all this work clientside.
Lightweight is definitely better.
Any thoughts? I looked into backbone, but it seems to be build around REST-ful interactions with a server-side model, which doesn't work well for me. JavascriptMVC looked really bulky for something this small.
Check out AngularJS which states that it brings to HTML what is required to use HTML for JS driven web applications. You can find a simple example of it's usage in form of a showcase of a very simple todo application on the starting page.
you should have a look at KnockoutJS, which is a JavaScript MVVM framework, which lends itself very well to what your doing.
You can use jQuery to turn the xml into JavaScript objects and add a little Knockout model magic and your UI will automatically update itself when the model changes.
You can use Backbone without server sync by creating your custom storage backend providing in-memory persistence
Look at a sample localStorage backend: http://documentcloud.github.com/backbone/docs/backbone-localstorage.html which overrides Backbone's sync method
I know it's not a true "MVC" framework, but you may benefit from checking out the jQuery template plugin - http://api.jquery.com/category/plugins/templates/ . You can create a template (in this case could be the XML template) that you can use to build the output from a JSON object. This would allow you to maintain the data in one place and allow the "rendering" to happen automatically from your data object.
You can use JavaScriptMVC via it's download builder: http://javascriptmvc.com/builder.html. Just check the model, view, controller and you are off! Here's a walkthrough of using just those parts:
http://javascriptmvc.com/docs.html#!mvc

Categories

Resources