Coming from non-JS html interpretation it's kind of hard for me to grasp the concept of loading server-side data to REACT.JS "view".
Let's say I've have a site built on Laravel (using routes). Each route request (e.g. "/", "contact") has it's own view. That view is loaded with data coming from a controller and displayed in the view. If I change the route I'll be redirected to another view and I'll get different data from a different controller.
Now the question. Let's say I have a simple site. Top part is my login information and maybe some notifications icon the content of the page changes with going to different sections of the web.
So If I keep using Laravel routes. Every page will be "re-rendered" + I'll have to manually select which components belong to that part of the site. I'll have to retrieve the information that stays the same from the whole web (e.g. login details + notification) again - this kills the react.js principle doesn't it?
Also, what is the best way to propagate server-site data to React.JS? Should I just "echo" out JSON object to the view and then "use" it in REACT?
Could I be pointed to some meaningful approach of how to use React.js along with PHP.
You mostly answered your question :-) With Laravel, the UI is rendered on the server. React is mostly interesting for client-side UI. That said, not everything can be done on the server, and some user interactions can only be managed by the browser. That is why jQuery became so successful in addition to PHP.
If your app deliver some complex client-side code, it could be usefull to build this code as React components, even if you keep your current server-side router: to make the code easier to maintain, but also to write - once familiar with React way of implementing things.
If you would like to transform your app to fully use React and a client-side router, that enable browsing the app without re-rendering at each page, this is called SPA (single page apps). The react ecosystem is pretty cool for building SPA. Usually, though, the server is just a static server delivering JS files, and the app connects to a REST API of some kind.
In some cases, routes can also be served from the server, for specific purposes:
Faster display of first page
Social Graph tags can be added to the specific page (to enable usable Facebook
or Twitter shares, for example)
Should you need to enable this server-side routing, which makes your app universal or isomorphic, you must use components that can be understood by both the browser and the server, this is why React app are usually served by Node.js, so everything is in Javascript.
Example tutorial about building a universal app with React https://medium.com/front-end-developers/handcrafting-an-isomorphic-redux-application-with-love-40ada4468af4#.h8p6lc23w (your intuition is right in this case, a JSON object with app current data is sent at first render)
Also check the awesome react page (https://github.com/enaqx/awesome-react) if you're interested in the React ecosystem.
Recap:
PHP + React: Easily add complex components to some pages, better to keep it that way if you just have a lot of static content, SEO, and just a few complex components on a single page that React can help you with.
React + API: Common SPA app, better for rich and complex UI, pretty easy to develop if starting from scratch and familiar with javascript, but complexity arise with performance management and SEO on large apps
Universal React: the best of both worlds, setup kinda complex (cf tutorial)
Related
I have a PHP app that uses Smarty. It is not using any standard MVC framework but achieves the same aim as follows:
each click that causes a page transition does it by calling a structured URL (akin to REST calls) that is interpreted by Apache rewrite rules (in .htaccess) into specific query parameters attached to the index.php file.
the index.php then determines which page or sub-page to load, performs whatever controller logic and then assembles the display info, loads smarty vars and then displays
I read somewhere that it's not advisable to mix front and back end MVC frameworks. I however need to convert the app in as short a timeframe as possible.
The typical combination is to have angular call a PHP REST backend. However I would rather keep all the deep business logic in the back end (not just CRUD actions) but have the PHP send back to my angular the data to be displayed.
I'm pretty new to Angular: is there anything that makes this technically impossible or suboptimal?
The typical combination is to have angular call a PHP REST backend.
Typical, yes. But not absolutely necessary. Your webservice can be structured the way you want.
However I would rather keep all the deep business logic in the back end (not just CRUD actions) but have the PHP send back to my angular the data to be displayed.
I might be misinterpreting you but, keeping your business logic in the backend is how it is supposed to be. Rest is not CRUD.
the index.php then determines which page or sub-page to load, performs whatever controller logic and then assembles the display info, loads smarty vars and then displays
The problem here is the "controller logic". From what I can gather you're trying to replace a server-side template engine with a client side template engine. That's fine. But AngularJS is not a template engine and there are some key points that might make it a bad choice in your case:
Angular is meant to work as a single page website/app. This means it expects pageflow and view logic, for instance, to be controlled by the client side. By keeping the "controller" logic in the backend, you turn Angular into an extremely inefficient and heavy template engine.
It expects the backend to serve (structured) data, not a "full" view. Sure, nothing stops you from requesting a PHP document. But it kind of defeats the purpose of using angular.
It plays nicely with REST because of its stateless nature. This
can be a bit of a challenge since it deviates from the usual PHP setup. The biggest example are logins and PHP sessions.
Usually, in most PHP setups, a user authenticates through a login form and then the server responds with a cookie, usually containing a PHPSESSID. While the cookie gets passed around, the user stays logged in and the appropriate UI/view/data is displayed. To adapt this logic to AngularJS single page app requires a bit of work. This article might help you
I'm pretty new to Angular: is there anything that makes this technically impossible or suboptimal?
In short... impossible no, far from it. suboptimal maybe...
I have previously used reactJS on another project.
When building said project i noticed a downfall namely the loss of SEO benefit associated with JS rendered components.
I am rebuilding an old project and I would like to replace some of the Javascript with ReactJS.
For example, a multi step form - I'd like to replace it with a stateful component that displays the correct stage as required.
I would however like to maintain the SEO aspects of the page by having the first step spiderable.
To achieve this my research implies that I should be using React's React.renderComponentToString
Having researched the issue my thought process is that I should render the components server side using node.js and then serve them up within the browser. The component is then re-added per say to add the client side functionality. My first question is as to whether this is a suitable approach? Is there a much simpler approach that I have overlooked?
Pete Hunt mentions here (https://groups.google.com/forum/#!msg/reactjs/eUespJPdyas/hmJywyo9ZSwJ) that Instagram uses/used Django and had a setup similar to what I imagined.
My app is written in php using phalcon. My question essentially relates to this statement:
Node will then return the HTML that makes up the component. Django
takes that HTML and inserts it into the DOM via normal Django
templates.
How do I go about doing this within PHP? I don't want this component rendered behind the scenes and used when requested, but rather rendered when required by PHP with passed parameters.
I found this question (Sending messages from PHP to Node.js) which got me thinking that one approach is to simply use CURL to query the port my node instance is listening on to get the html which I then output.
My concern here is that all my experiences with CURL have suggested that it is very slow. I don't want my page load times to decrease dramatically just to get some SEO benefit.
Could anyone advise on the above questions/my direction?
Many Thanks
Stoyan Stefanov created a library for calling into the V8 JS library from PHP code for doing this sort of thing; it's available here:
https://github.com/reactjs/react-php-v8js
You can read about how he set up React server rendering in these two posts:
http://www.phpied.com/server-side-react-with-php/
http://www.phpied.com/server-side-react-with-php-part-2/
Rendering won't be instant, but it should be reasonably fast. If you're having performance problems and caching doesn't help, you can consider using Google's AJAX crawling feature in order to use server rendering only for Googlebot but not normal requests:
https://developers.google.com/webmasters/ajax-crawling/docs/getting-started
Note that browsers will also take advantage of server-rendered markup so even if the initial request is slower, rendering may be faster.
I recently started to build a large social network, and and I thought my structure was good but it turned out I built this logic up badly.
I mixed my views with AngularJS (bad idea), skipped blade extension, but since I'm using a lot of block and sidebar includes it became a pain in the butt.
Currently I am just handling form validations with angular, but actually all of my site pages will require ajax, data pulling, etc.
I was searching around the net and I saw that angular views are stored in the public folder, but since all my pages will use angular is it a good idea to store all my views in the public, and just use Laravel as a back end?
I know this is a silly question but I'm confused a bit.
Any help hint appreciated.
There are two ways to combine these frameworks:
Only client-side rendering
This is the easier way and used by most web applications. In this case you would use Laravel as an API endpoint which will return JSON. Angular can query this data through its $http or $resource service and compile the templates, which you store in the public folder. Angular templates are just HTML with directives and some {{var}} statements. This way Angular does all the routing too.
Server-side and client-side rendering
This is the harder way where Laravel would do the routing and compile some templates on the server-side. You would use Angular only for some interactions on the site in a way you would use jQuery for example. The benefit of this approach is performance as users will get the full HTML the first time they visit your site. The disadvantage is that you may have to write some logic twice and can’t use some of Angular’s features.
To actually benefit from most of angular's features you should write a Single Page Application. This means you will communicate with the server through web APIs and you won't have any Laravel server-side templates.
So yes, you should write two decoupled applications. One client-side, using Angular and one server-side that exposes a web API, preferably RESTful.
This way you could switch from JS/HTML/CSS on the client side to Flash or Silverlight or something else and from Laravel/PHP/MySQL to .NET or NodeJS or Meteor/MongoDB.
Sergiu is correct, but in some cases Laravel still offers benefits that cannot be achieved with client-side templates. This is related to SEO and WCAG (accessibility).
AngularJS renders content by way of DOM manipulation so search engines cannot determine what content is shown after those manipulations are complete. This is also the case for screen readers. For this reason some content must be delivered by way of server-side view constructs. That is why Wordpress and Laravel have long and healthy futures.
On the back-end or in cases where SEO and WCAG are not important, data binding client side templates such as those used with AngularJS and Ember will be used increasingly as more developers learn how to use them.
In terms of whether to use AngularJS or Laravel for view constructs it would be best to learn how to use both and apply where most appropriate.
Maybe it's not a real question, rather is's a discussion. I decided to learn angular, using a simple task, build a blog system. And i have a few questions.
Lest imagine that the php app will have the MVC structure, so i have some questions:
Should i build my back-end only as RESTFUL app, and use json response\request upon the angular and php?
What about the view in php app, i should use them with ng-init?
Routing, server side or client side?
What about caching?
And the last, but not the least, where i should put the logic about data that user will input?
Can someone give me the instructions or directions, about this things, and maybe useful link's to read the articles, to combine the php and angular, or maybe i'm doing it in the wrong way?
You might want to consider this type of application as actually TWO applications.
The first is the backend, the API. You can use your PHP framework to build an API that will allow you to have data persistency, validation (business logic), etc... and forget about the front end for now, you are only building an API for the backend data.
The second part of the app is the AngularJS frontend. This includes all of the views and everything that the client sees. None of that is coming from the backend.
This allows you to use the backend API (the PHP bit) to act as the data store, with it's own validation for safety, while having the seamless user experience and basic client side validation from AngularJS.
Routing is AngularJS, as that is the actual frontend that the client is using.
Caching can be done (if needed) in the backend, your API.
Validation will happen in both the frontend and the backend, although they can be slightly different if need be.
Remember, you build the backend strictly as an API, without consideration for the frontend (as if there will be more than one app using it), so it will have it's own validation rules and logic.
Hope that helps.
I have found a very simple structure that allows me to utilize Angular with PHP and restful api's. I use Angularjs for all views. I use a restful PHP API framework called slim to facilitate the communications between Angular and the PHP models which I use Doctorine2 for.
85% of my coding is done with Angular(Views). 5% done with the API(controller) and the remaining 10% configuring business logic in the Models. Great separation of concerns and not much overhead. Simple and concise.
So I have decided to take a project I have been working on, and project management system, and convert it from a standard multi-paged application to a single-page application. In the process I have looked at a number of javascript MV*ish frameworks (ember, knockout, backbone, etc...) and have decided to go with backbone.js as it seems the most flexible solution and that I already use underscore.js for both its utilities and template system.
The one biggest concern I have with doing this is the potential code duplication I am going to have for model and business/domain logic in both my PHP models and in my backbone models.
This is just a technical cost I have pay when going with an architecture like this or are there some things I can do to lessen this concern?
You may want to take a look at a previous question I answered involving Node.js:
Reusing backbone views/routes on the server when using Backbone.js pushstate for seo/bookmarking
What I'm currently doing right now is using Davis.js + Mustache + Java Spring MVC backened (based on my original question: Single page Web App in Java framework or examples?).
If the browser does not support Pushstate then I have the server do the entire rendering of the page using a Java version of Mustache (ie standard Web 1.0). If the browser does support Pushstate then the browser will make an AJAX request for a JSON version of the model. The model is then rendered client side use icanhz (ie javascript mustache).
This works fairly well if a large part of your logic is getting a model an then rendering it based on specific URL. That is your business logic is "based on some URL I'm going to render this". This is how most of the sites on the web work (including this one which is still rather web 1.0). Obviously this would not work for say something like real time chat or HTML5 game.
A python version of this design is mentioned here: http://duganchen.ca/single-page-web-app-architecture-done-right/
I'm sure someone has done a PHP version.
If you are using different languages in server and in client I think there is not possibility to avoid this partial logic duplication you are concern on.
If you definitely want to use same code in server and client you have to move all of it to the only common language: JavaScript.
There are multiple JS frameworks those integrate very transparently the development between server and client: derby, meteor, ...