I was wondering to use paypal's React Engine (https://github.com/paypal/react-engine), but I have some doubts:
What are the benefits over other template engines like Handlebars?
Why upload .jsx files, and not (jsx precompiled/transformed) .js files? (This one should be faster because don't have to do deal with the transformation at the server).
I have been researching but I get confused.
Thanks
The main difference between react-engine and template engines is only when the browser enables the user to interact with the browser page. Nevertheless, it is important how machines have access to individual data.
Assuming we want to run a simple webpage. Just a scrolling and open text information. Using template engines, like Handlebars.js, typically, when the browser request hits to the server, it tries to figure it out how to respond and what to do. That said, the template engine may reference existing fetched data from files stored into a local and accessible source. Those are loading all the defined data regarding the site template file (i.e. head, meta, title, etc.), with a render of incomplete HTML string. This HTML is then sent back to the Browser and rendered.
The react-engine, on the same side it happens the use of the same rendering mechanism. However, instead of a template engine semantic, it uses JSX, or if we want, we can also use JavaScript. The JSX is, therefore, broader then template engines. A great article by Hajime Yamasaki Vukelic complies the separation of concerns from a different angle between JSX and HTML templates.
With template engines, you feed the library a string (usually but not
necessarily HTML), which is then converted into a piece of JavaScript
code which generates virtual DOM structures when executed. At design
time, templates are just strings, so we don’t have direct access to
the surrounding code. For instance, we can’t import helper functions,
or call methods. These things are only possible through abstractions
called directives (and possibly other names depending on where you are
coming from). Directives are the glue between the HTML and the
JavaScript.
So far so good, there is no relevant difference between both solutions. Links to next or previous simple webpage are just simple <a href="/webpage>Next</a> elements.
At the moment, when we decide to implement some interactions, react-engine will be the winner. While react-engine rendering does not require JavaScript to run on the client side, it will enable SEO over the search.
Template engines also have this SEO support, but with less impact. We can not run here all JavaScript to render HTML. Even libraries like jQuery require live access to the browser window object which cannot be mocked easily on the server side. So template engines become less productive.
In conclusion, template engines can do the same as react-engine rendering. Maybe not equally easy or equally fast but both tools are qualified. You can also read another great thread on this topic.
Related
are there any utilities or approaches to export regular react component into an email friendly static html?
for example i have a dashboard using react-table and would love it if there was a way to auto-magically translate that to static html i could insert into an email body.
i can think of a few approaches using a headless browser to render as pure html, but it would be awesome if there was a solution with more email friendly html
Because the layout of these gets fairly complex, it may also be advantageous to render page as image and insert that image into email body?
I only really know HTML Email, and basics of React - and SO is not great for recommendations of software type questions - so I'll just speak to the email side.
If you can get HTML, you need to consider a few things.
First, anything over two columns is likely to run out of space. You would need to consider a stackable column structure with repeated headers. That would require hiding the duplicated headers for desktop views, since the tables would be separate due to the way we do stacked columns in emails (as inline-blocks without media queries). See https://medium.com/#nathankeenmelb/bulletproof-responsive-datatables-in-html-emails-64248b9e18f5 for full details.
Second, only some approaches would work like that. Images then would be your go-to option. A nice output for table images would be:
<img src="https://via.placeholder.com/600x500" width="600" style="vertical-align:middle;width:100%;border:0">
The link goes to the image itself so you can zoom and move around easier, and get maximum realestate.
An alternative built on that idea would be to have a link from the image to landing page with full web capabilities. That would take longer to load, but may be well worth it.
Since that's probably the most viable, I'll explain these choices of attributes and styles:
Use the width attribute width="600" because that's what Outlook desktop uses
Use inline styles for those email clients that do not support <style> blocks
Vertical-align:middle (or display:block) removes the space underneath the image that some email clients add
width:100% makes it responsive to mobiles
border:0 ensures no border is shown because of the link
Third, datatables are so finicky and particular in HTML email. Each table is unique because they have different data in them that responds differently. In normal web design, you can just use a nice reset and get everything working without much thought. In HTML Email, everything needs to be inline, and supported, with fallbacks for those things that are unsupported. So even the core data often needs editing - e.g. if it has long URLs, emails or words you need to add a wrapping span with word-break CSS but also <wbr>s in the middle of it for some email clients to properly wrap.
Datatables don't often come up, and because of these considerations, it's hard to see how they could be automated easily - and hard to build a case for it financially.
On a related note, if you can show the information using card UI, that seems to me to be a much nicer, simpler, more accessible and easier to code solution than datatables. This is about taking the information and redesigning it into card blocks. I talk about that in detail here: https://medium.com/#nathankeenmelb/responsive-datatables-through-card-ui-design-for-email-aca6f3c395a2
I did look through the similar questions and found this one, but the answer there isn't, at least by itself, dynamic enough for my needs.
Similar to that question, I am attempting to put together a multi-tenant application with a different skin per property. However, the answer given in the above question assumes that the various skin resources can be hard-coded into the application. That would be fine if we were talking about 2 or 3 skins, but my application will need to support dozens at launch and probably tens of thousands in its lifetime (each property can create multiple skins for different campaigns).
I have an API where I can request the skin, which is currently a long string of HTML with a token embedded indicating where the application contents should be rendered into the skin (e.g. {{body}}).
One of the things I'll need to do is inject some <link> tags into the <Head> element to pull in some external CSS. If React.Fragment supports attributes (like __dangerouslySetInnerHTML), I haven't been able to figure out how. If it's possible, that might be one way.
I'll run into the same problem when I want to inject some pre-application and post-application content into the body of the page, too.
Since I want the skin to be rendered server-side on the first request and then be static until the tab is closed, it makes sense to do this in pages/_document.js. After that, I'm kind of lost for what to do next. Parsing the string that contains the skin content is easy enough, but how do I intermingle that raw HTML with React components?
The application I'm developing uses "angular.js" + "ui-router" + "bootstrap". Many states and nested views. There are also some images related to templates and, finally, animated transitions placed there to generate feeling of fluidity.
Under ideal network conditions, the application works reasonably well.
Under poor network conditions, it is bad. Sometimes animation flicks, sometimes there is a pause between the user action and the response of the interface. (for instance: the start of an animation). The feeling of flow can not be achieved.
The problems are noted when "ui-router" changes its state, the application seems to lock or flicks animations or there are sudden jumps.
The application is to be used from devices with limited bandwidth due to its geographical location.
Can I preload all or part of the application, including images and others assets?
You can concatenate and minify all JS & CSS assets (if you are not already doing so). I use grunt-neuter for dependency management. You can also bundle all the dependent libraries together (I use grunt-usemin).
I have not tried to bundle all the templates into one file, but that should also be possible. In that case, you would wrap each template within <script type="text/template"></script> blocks, have everything in DOM, and pluck out individual templates and provide to each route. This should totally eliminate flicker.
For image assets, there are grunt plugins such as grunt-spritefiles that takes a bunch of images, and create a sprite, which then can be used within your CSS.
These are some of the techniques I can think of. However, the above can significantly increase the first time load. It may be acceptable for the use case you are describing. Hope this helps!
My team was considering using angular js for web app UI development. But knowing at a high level how single page apps work, I had a question as to, how feasible it is to use angular js framework, for a large web application. this would have at least 200 screens, each screen containing an average of 30 UI controls like text boxes, calendar controls, drop downs etc.
The user will be accessing the web app on desktop or laptop and will be using the application in the browser throughout an 8 hour day, without ever closing the browser.
Given above usage, would angular js, memory usage / performance be issue?
are there web apps with huge and complex UI, built using angular js, that are in production and used everyday?
You can have not just 200 but 1000's of screens - this number does not matter as long as you address the core and fundamental questions below. They all boil down to memory and performance.
At a given point of time how many $watches will be active.
At a given point of time how many listeners are created.
At a given point of time what is the complexity of DOM i.e. the number of DOM elements and thee nesting/depth.
At a given point of time how many Javascript modules (services, controllers etc.) will be loaded in the memory. Even though these things are singletons they consume memory.
For each such screen how much memory will be consumed (if you use jqueryUI etc. your memory increases quite rapidly than pure angular + html components)
This brings to what you can do to control the above factors which if not watched will make your application sink/crash.
1) How do you break the run-time complexities of your "big" application ? You can now think of "Routers" or dialogs. Each of your screen will come-and-go i.e. you will never display 200 screens the same time.
2) Make sure when the screen is gone there is no "leftover". Don't use jQuery - if you do make sure you clean this on $scope.$destroy.
3) Multitudes of directives:- Directives are powerful but don't over use it - try not to deep nest too many of them. templateUrl is "tempting" but sometimes in-lining a template is the best choice. Use build tools that will inline the templates.
4) Load modules on demand using requireJS. This will force you to modularize your application and think hard about concatention strategy (combining JS files). Will force you to write independent modules.
5) Browser caching your assets and a good cache busting mechanism. Grunt based plugins are to your rescue. Minify your assets.
6) Compresss the assets for efficient network utilization and faster transmission.
7) Keep your app encapsulated in Angular. Don't create any global objects. Chances are that they have access to some closure or are referring to some things within angular $scope and $scopes are now still hanging on or are in difficult trajectory to be able to get Garbage Collected.
8) Use one-time-bind or bind-once model binding as much as possible.
9) Splash screen is an excellent weapon - us it. Helps you load some stuff upfront while the user watches smooth/jazzy picture/picture :)
Regarding 8 hours a day constant use
Unless there is a leak of the following kind you should be fine:-
1) Listeners leaking i.e. hanging around.
2) DOM leaks. Detached DOM issue.
3) Size of Javascript objects. Javascript objects coded in a certain way creates repeated instances of function.
(I am developing AngularJS app - with more than 450 screen - MDI like app. The app is not yet in production. The above points are coming from my burnouts in the functionality we have developed so far.)
I've worked on multiple projects that are extremely large single-page applications in Angular and Ember.JS at companies like McKesson an Netflix.
I can tell you for a fact that it's completely "feasible" to build "huge, complex" applications with frameworks such as Angular. In fact, I believe Angular is uniquely well suited to this because of it's modular structure.
One thing to consider when creating your Angular application is whether or not every user will benefit from all "200 pages" of your application. That is to say, is it necessary to have all 200 views be part of the same single page application? Or should you break it into a few single page applications with views that share concerns.
A few tips:
Watch out for name collisions in the IOC container: If you create enough services and controllers, even if you break them into separate modules, it's very easy to create two services with the same name. This may or may not result in an outright error. What happens when you register two "fooService" services? The last one wins.
If you decide to break your app into more than one single page app, you have to be sure you have solid boundaries of functionality between the two. They're not going to be able to share state easily other than with something like cookies or local storage.
If you decide to keep everything in one single page app, you're going to want to keenly watch your initial download time. Always check to see how long it takes to start your app "cold" over a slow-ish connection. If the entire app is in one bundle, depending on how you structure things (are you going to use AMD?) then you might see a long initial load time.
AVOID rendering HTML on your server. I can't stress this enough. Let Angular do that work for you. The only rendering your server should be doing is rendering JSON to be returned from some RESTful service.
Flush out your JS build process early on. Look into Node-based tools like Grunt, Gulp, and Broccoli for linting/concatenating/minifying your JS files. Checkout Karma for running unit tests, and look into Istanbul for code coverage. Protractor is a great tool as well, but I recommend strong unit tests in Karma over integration tests with Protractor just because Web Driver based tests tend to be brittle.
Other than that, I think you'll find a single page app written in any modern framework to be extremely snappy after the initial load is done. In fact, it will make any "old" PHP/ASP.Net style app that renders the entire page at the server seem slow as dirt in comparison. This is because you'll only be loading data and the occasional .html file over HTTP.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working with a web where many queries have to be performed to a MYSQL database. I use Java+Tomcat as development environment.
I have tried different ways to solve this:
At the beginning I started using jstl with the sql tag. Every jsp document created this way seems 'dirty' with many sql queries using the jstl sql tag and you have to change every document when the DB changes.
The second solution I tried was using lists and maps in servlets to access the data from jstl el. It looks fine but seems a bit strange -at least for me- to have to access each document with a custom url (firstly you manipulate the data with several classes until you set the request attributes and call the jsp document RequestDispatcher) and sometimes it could fail (missing queries needed to fill some menus or tables) if user jumps from here to there in the navigation sequence.
The final solution I'm trying now is sending and receiving JSON data to/from server-side. I like it (everything happens in the same url context, the html document part is clean, more dynamic web...) but JSON data have to be processed with javascript in client-side, which could affect the performance for large data chunks, and maybe have some size limitations due to the string format. For example JSON works fine for data splitting using DataTables js library where I only get a max -I set this parameter- of 200 rows at the same time from a DB. But it slows the web when I don't perform this data splitting and show, for example, a multiple combobox or a table with all the rows inside a table in the MYSQL DB.
Some years ago I developed a desktop app (C#) with embedded flash for navigation and xml for data exchange between DB and APP. But I think XML is better for data exporting among different apps, I don't need more files with partial data if I already have a DB.
So, guys, what do you think is the best solution? I would like to check different points of view.
Dump JSP tag libraries and switch to JSON.
I often see development teams using JSP tag libraries when they shouldn't be. I wrote this post to explain why it's best to view JSP tag libraries as relics of the past.
Most non-trivial web applications store data in a database on the server side. These applications need mechanisms that allow the clients (web browsers) and servers (e.g. Java application servers) to exchange data. Typically, either a) data needs to be displayed for the user (so, the client sends the look up criteria to the server and the server responds with the relevant data) or b) the user changes data in the browser and the client needs to submit the data modification to the server for processing and/or permanent storage.
Until recently, most Java web applications have used JSP tag libraries as a client-side mechanism to extract data out of Java objects (JavaBeans) passed back and forth between clients (web browsers) and servers as part of the JSP/servlet paradigm offered by Java. (Note: JSPs are HTML files that get converted into Java servlets so that they can contain Java code for manipulating server-side Java objects.) In each case, the server responds with a new page (with embedded data), also known as a full page refresh.
In 1995, AJAX came along and changed the full page refresh paradigm described above. AJAX allows for partial page refreshes and data exchanges between the browser and the app server without having to do full page refreshes.Since then, AJAX has continuously gained momentum with support built into popular frameworks like Spring (for Java) in v3.0/2010 and jQuery (for JavaScript) in v1.5/2011.
The data exchange format that works best with AJAX is JSON, since JSP tag libraries cannot be invoked unless a full page refresh is involved. There are several options for mapping between the server-side Java model objects (JavaBeans) and JSON, which can easily be consumed by JavaScript running in the browser. (Note: Since JSON is the literal representation of a JavaScript object, the conversion from JSON to JavaScript object is trivial.) The option I recommend and have been using is Spring MVC's #RequestBody and #ResponseBody annotations as part of the controller method definitions (which leverage the Jackson library) to automatically map JavaBeans to JSON and back (see figures 3 and 4). (The alternative is to use a proprietary framework like Direct Web Remoting or DWR, which I do not recommend for obvious reasons.)
As a result, I recommend to most teams I consult with that it's best to abandon JSP tag libraries entirely in favor of a pure AJAX/JSON based approach.
Here's a summary of the reasoning behind my recommendation to use AJAX/JSON exclusively (even for full page refreshes).
Unless, you have a very simple application, you will likely need to support partial page refreshes using AJAX (rather than do a full page refresh each time that some data needs to change on the page). To do so, you need to map between Java objects (JavaBeans) and JavaScript objects (JSON) in order to exchange data between the browser/client and the application server. Therefore, it probably doesn't make much sense to support two channels for data exchange (JSP tag libraries for full page refreshes and AJAX/JSON for partial page refreshes). And if you have to pick one it has to be AJAX/JSON, since JSP tag libraries don't work for partial page refreshes. Hence, my recommendation to go head first with AJAX/JSON and abandon JSP tag libraries. But if you need more incentive, please read on.
I have worked with teams that have analyzed the size of the data being shuttled back and forth across the network and found that JSON consumes a lot less network bandwidth than the JavaBeans/JSP tag library approach or even XML payloads. Their analysis seems to make sense to me since JSON is a bare bones pure text format without the syntactical overhead involved with XML or the rich object overhead involved with JavaBeans.
Relative to the acrobatics required for manipulating JavaBeans using JSP tag libraries (see figure 1), the JavaBeans to JSON mapping is completely seamless with Spring MVC and requires no coding whatsoever (see figure 2). Whether or not you're using JSP tag libraries, chances are that you need to populate JavaScript objects with the data in order for the data to be consumed by jQuery widgets. In other words, the JavaScript object(s) are required in regardless of whether you use JSP tag libraries or not. Abandoning JSP tag libraries allows you to skip step 2 (see figures) and go straight to JSON and the corresponding JavaScript object(s) without having to muddle through the manipulation of JavaBean objects using JSP tag libraries.