It seems that angular.js and backbone.js both prefer the user to change the browser state (via the address bar) and then they will re-act regarding the defined routes. That is still a single-page web application, but in my case, I really don't need to change the address bar when user is interacting with the application and I prefer to avoid it as much as possible also.
As a newbie in both angular.js and backbone.js, I'm facing difficulty on how to structure my single-page web application while using either angular.js or backbone.js, but without touching the address bar.
I have a node.js, jade and socket.io setup (without express.js), and the socket.io is the main way of communication between client and server.
To be more specific, imagine that I'm loading the dashbaord.jade, now how can I inject some partials into the main markup when socket.io detects an event? Can I replace the entire dashbaord.jade also - the already rendered markup?
So what's the problem? Don't change the url! don't use router and make your app just interact with user by mouse (or keyboard) events or just update model or views every single time socket send event!!
My solution : don't create any router, implement new class to use socket and by any event of socket do appropriate action. In that class define a method for each socket event, that loads template and model (maybe return data from socketIO event) and render view by those data.
Related
I am using reactjs and nodejs for my application. I am calling the api created in nodejs in my react js component. Let's suppose, I have a component User. And i am calling api in componentWillMount function to get a list of users. So when a new user is added by add user component, The change is not reflecting to list of users. So i need to use socket.io to make application real time, so that my list of users can get something is updated in database and its time to render the component again.
Is there anything regarding above?
You could use Socket.io for updating the users list. Another option is to use server-sent events (for more info on the differences between the two, see this answer).
If you choose to use Socket.io, you can emit an event from the client once a new user is added. Once the server receives that event, it broadcasts it to all other connected sockets (using socket.broadcast.emit). The sockets listen to the users-update event (an example for this can be found here), and once they receive it, the client should update the User component and rerender it.
If you choose to use SSE, check out this article.
If you want to apply data from response of api to rendered component, I recommend you will call api on componentDidMount.
It is the great way.
Of course, you can use socket.io
Given that we can do routing with Express on the server, why do need a client side router?
What are the benefits, and is it only significant to SPA?
Client side routing is required to keep your application in sync with the browser URL.
It is mainly useful for Single Page Applications where the backend will be used for RESTful API calls via XHR or AJAX calls.
Being a SPA uses can book mark your URL and when they hit the URL again , your application should load that page with the data and its state.
The main difference between Server side routing and client side routing:
1. In Server Side routing you download(serve) the entire page.
2. In client Side routing along with the entire page, you can serve a specific portion of a page, reuse the DOM, manually manage the URL and history states. eg.
www.something.com/page1/tab1 will show tab1 in the UI
www.something.com/page1.tab2 will show tab2 in the UI
In this way the url can get more complex and you can have sub-routes with states.
Those who need a client-side router, need it for state management. Say you have server-rendered pages, but with some client-side widgets - e.g. a calendar, set of filters or collapsed or open sidebar. Router helps you initialize these components of the page in the exact state you want them. Granted, you could do most of it and all of the use cases I've named on the server, too. But it's usually a lot easier to handle these on the client. You might render it faster on the server, but sometimes, especially when doing partial page updates, it's cheaper and faster to handle that client-side.
I've recently dived into React+Flux on the front-end, and I love it! But I want to also be able to use React on the back-end to avoid having to duplicate views and rendering logic.
I've seen that React supports server-side rendering if you use Node, but I do not use Node for my back-end logic.
So I'm wondering, can I set up a daemon written in Node that just renders HTML based on the data it receives and the root React component?
What I have in mind is to have my back-end application call this daemon with data already prepared (so that domain logic can live on my main back-end application), get HTML, and return that to the front-end.
Is this approach feasible? Has this been done before? I'd love some feedback!
I see that it's been a month and there are still no comments, I will share some of my understandings.
We can use this setup:
An API written in PHP or something similar that serves data.
Isomorphic React components - render on the server, attach event listeners on the client.
Server-side (Node) - the React component uses AJAX calls to get its props from the API and embeds them into a <script id="props" /> tag in the HTML as a JSON string.
Client-side - the component checks the script tag for props. If there is data, then it uses that to skip the re-rendering; if not (due to a server error or something), it can still use AJAX to get its props.
The main idea is that the website is isomorphic (server and client share the same code), so your existing front-end can be easily adapted to this setup.
A good place to start is a simple example about isomorphic React components. This tutorial can also provide an overview to this subject.
I am making a webapplication with multiple pages using nodejs, express & socket.io. One of the features is push notifications. This means socket.io should be running on every page. Connecting to socket.io on every page load takes a lot of time, which slows down the app.
Is there a way to keep the connection to the socket open?
One way would be to use ajax to render different pages inside my root page, but I think this will over complicate the app.
Is there a better way to implement this?
Are you sure you're handling the client side the right way ?
If you have a single page application, the browser should almost never reload completely the page. You should be using some client-side framework to handle SPA mechanisms (routing, templating, etc) like angularjs/backbone/ember/etc...
With a well formated SPA you load your app only once and it is kept alive without page reload as long as the browser tab is opened. So you weboscket would be created also only once. You shouldn't have any problem of this kind, your server side code is OK, it's just that you're doing it wrong client-side.
By the way, if you want to do handle only push data, you should take a look at the Server Sent Events, which is simplier/lighter that a full-duplex implementation like socket.io (which is a bit heavy)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Reusing backbone views/routes on the server when using Backbone.js pushstate for seo/bookmarking
I am using Backbone.js and bunch of other modules to handle Single Page App method. My goals:
The site must be SEO-friendly
Server bootstrap html code to client and data stored in JSON models.
Sub-sequence actions are all handled by Javascript (e.g. render new screen, change url using Backbone router).
My question is: how to structure the server to align with Javascript on each router url and keep it DRY?
For example: if user goes to wwww.mysite.com and then click on some link to go to www.mysite.com/page/2, it must be the same as having him to go to www.mysite.com/page/2 directly on first load.
This seems to be an old topic but I cannot find any solid resource about best way to handle this on server side without repeating the template code in Javascript.
One option I am thinking is to split backend into Node.js and another server to handle API only. The Node.js server somehow share the template construction code as the Javascript frontend
Anyways, love to hear some advice and apology if this is not the right place to ask such question.
I would treat my node server as just a REST interface to my data. I would then handle everything else client-side: I could load templates using require.js with a template plugin like jade, do all my routing using Backbone.Router, and then access my models and collections using Backbone.sync methods (like collection.fetch().)
So for example, when a user accesses "mysite.com/#page/2", I could get my Backbone router to load and display whatever template would be on the page. If I happened to need a list of products to display on that page, then I could make my product collection do a product.fetch(). That would send a GET request to "/products" -- or whatever URL is specified in product.url. My node server would then respond with an array of product objects that the view my collection belongs to could use in rendering itself.