Node validation in jade template - node.js

I'm extremely new to node.js, and have years of experience in PHP, so my thinking about the issues below, might be tainted by my backed ways.
I'm currently using node set up with foundation CSS, and using their reveal modal windows to display most of my forms. I want to avoid re-displaying them upon submit, and instead, validate them on client side.
Basic user creation will have fields as per below:
name
email
password
password confirmation
Form my basic validation i can use require to validate the input,
input(type="text",name="user[email]",placeholder="#",required)
but I would also like the client to check if the email already exists after the user types it in, and whether the passwords are correct.
I've been reading about the validator module but from the documentation I read about it, I only understand how to validate the values after they've been posted. I've seen the express-form module as well, but It's no longer maintained, so I would rather avoid it.
Could someone point me in the right direction?


I don't have any experience with validator or express-form, and I am not sure you need them for what you are trying to achieve. Most of what you are trying to do will be client side work (e.g. jQuery Ajax calls to validate the data) That kind of client-side code should be pretty much the same regardless of whether you use a Node.js backend or a PHP backend.
Injecting the initial JavaScript in your Jade page should be pretty straightforward once you figure out the proper syntax to include JavaScript in a Jade page. The wiring of DOM events on the page to make Ajax calls (onClick, onTextChanged, et cetera) will be conceptually the same as if you were writing a plain HTML page.
In your Node.js server side you'll need a route to handle the request to validate if an e-mail address already exists and that code very likely will return JSON that you will use in your client side form to display the results of the validation to the user. But that should also be very similar to what you would have done with a PHP backend.

Related

What is the right way to accomplish live input validation in Angular and Node.JS?

I'm trying to accomplish live input validation through an API call (Using Node.JS) in Angular 9.
What would be the most practical approach to this problem using the native utilities provided by Angular?
What I considered doing was to have oninput callbacks which send requests using fetch, then change the disabled attribute on my submit button accordingly - but I felt like this approach was not the best approach considering my framework selection.

You should use ajax, send email value as parameter then catch it on node then run query if it has record then response it.

Sending data without redirect?

I want to send data to the client without having it redirect and show the data in the browser. The server is written in node.js using express.js.
It is for a login function.
I need to have it work like this since the idea of the system is to use the front-end purely as a GUI for interacting with the API.
res.send("Login failed").redirect(homepage);
I've seen framework-engine which I suppose I could use, but I would like to avoid as much additional "software" as possible. Essentially my question is: How do I send data back to the client so that it can be used in an already shown HTML page.

Can server side rendering in React be helpful with dynamic presentation?

My issue: For my thesis I am creating an auction site. I have an admin panel in which I would like to have some configurations so that an admin can specify that if there are 10 days before the end of an auction some components should be displayed in different ways, some should be not visible at all etc. That’s what I call dynamic presentation.
My question: Right now I am working on architecture and wondering if SSR can be helpful in any way? I am already aware that it can shorten download time of some collections from my database even by half, but I am wondering if there is any way how it can be helpful with dynamic presentation itself?
What I already know: I have read all about advantages and disadvantages of ssr or universal rendering in react. Now I am only wondering if it can be in any way helpful with dynamic presentation or it won't matter if I choose SSR or CSR.
Small side question: I don’t have the whole architecture ready yet. What I know is that I would like to have a database, one separate app for an admin, backend and frontend (either ssr or csr). My first thought on how to manage this dynamic presentation was to store some rules in the database. Then the rules could be configured in admin app should an admin want to change anything. The rules should be send to backend and calculated with some additional data from frontend. Then backend could send some flag to frontend indicating which components to display etc. In theory I could move calculating to e.g. NodeJs server should I go with SSR. What I'm wondering about is; can you think of any better way to handle dynamic presentation? What I am most afraid of is numerous ifs in the fronetend. I would like to have some more elegant solution but I have no other idea so far. For some time I thought about a scoring system but I believe it would be too complicated (instead of sending a flag, send a score and frontend will display correct things based on the score). Also it wouldn’t solve the issue of ifs on the frontend.
I am aware that on StackOverflow questions which can be answered rather than discussed are preferred but I am really stuck and would appreciate help.

Basically SSR can provide some speed on your page because all of your data will not be trying to be fetched when the react script will end with an API call. Data are fetched from database when page is requested and be passed to the component to render with the script.
Also another very basic advantage and the reason why everyone are going the SSR way is SEO. You cannot achieve SEO page with react CSR. This is because google bot etc will try and crawl your page without even render it. Is like trying to "view source" of a page. When you are in CSR the page has no content only the initial react divs empty. You need SSR to have data on the first request of the user.
SSR brings the data on the first request of the user until a reload. In the meantime react router fetches data from the api.
Let me know if that help you.
PS: also a helpful link https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

Which method is faster, express : Server-side rendering vs client-side rendering

What I would like to know is, how do you built your web application? I'm really confuse as which method should I use for my project.
Already decided which technologies to choose.
1) Node.js and express as its Framework
2) MongoDB
3) React + Flux
But the problem right now, should I use method (A) or method (B)
Method (A) - Serverside rendering for HTML
app.get('/users/', function(request, respond) {
var user = "Jack";
respond.render("user", { user: user });
});
Method (B) - Clientside rendering for HTML
app.get('/users/', function(request, respond){
var user = "Jack";
respond.json({ user: user });
});
Method A will render the HTML from the server and as well as the data.
Method B will just respond the data that is needed for the client which is React.js, so that it could manipulate the data.
My concern, is which method should I use? most startups use which method?
Thank you.

It's not an either/or proposition.
React is a client side framework. You have to render on the client side. The question is whether to render on the server side in addition to rendering on the client side.
The answer? If you can, YES!
You will get SEO benefits and an initial performance boost by rendering on the server side. But you will still have to do the same client side rendering.
I suggestion googling "isomorphic react" and doing some reading. Here is one article on the subject.
http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/

Well, it really depends on which vision you have on the modern web, and what you are willing to do.
Will you prefer to let your users wait, displaying a loader while data are loaded asynchronously, or will you prefer to keep your users busy as long as you can ?
Here are different articles that will help you clear your mind and be aware of the different advantages that you can have by doing server-side rendering, client-side rendering having multiple issues.
You can see this post from Twitter blog saying they improve their initial page load by 1/5th to what they had before, by moving the rendering to the server:
https://blog.twitter.com/2012/improving-performance-on-twittercom
An other article, this time from airbnb, describing the issues you can have with client-side rendering itself:
http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
There is also an other interesting article talking about client-side/server-side rendering, bringing a debate on when should we use / not use server-side or client-side rendering and why:
https://ponyfoo.com/articles/stop-breaking-the-web
And to finish, I can give you two more link more focused on react, and describing in which way server-side rendering should be helpful for your case:
https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html
http://reactjsnews.com/isomorphic-javascript-with-react-node/
Now, about what you SHOULD do, it's a matter of what you exactly need to do, to my opinion, but basically, you can do both at the same time (client-side AND server-side), to have the best user experience.
This concept is called "isomorphic javascript" and it is getting more and more popular these days.

The simplest architecture is to just do dynamic html rendering on the server, with no Ajax, and with a new HTML page requested for pretty much any client click. This is the 'traditional' approach, and has pros and cons.
The next simplest is to serve completely static html+js+css (your React app) to the client, and make XMLHttpRequest calls to webservices to fetch the required data (i.e. your method B).
The most complex but ideal approach (from a performance and SEO perspective) is to build an 'isomorphic' app that supports both approaches. The idea is that the server makes all the necessary WS calls that the client would make and renders the initial page that the user has visited (which could be a deep-linked part of the application), a bit like option A but using React to do the rendering, and then passes control to the client for future DOM updates. This then allows fast incremental updates to the page via web-service calls as the user interacts (e.g. just like B). Navigation between different 'pages' at this point involves using the History API to make it look like you're changing page, when actually you are just manipulating the current page using web-services. But you you then did a browser refresh, your server would send back the full HTML of the current page, before passing control to client-side React again. There are lots of React+Flux+Node examples of this approach available online, using the different flavours of Flux that support server-side rendering.
Whether that approach is worthwhile depends on your situation. It probably makes sense to start using approach B (you can share the your HTTP API between mobile apps and websites), but use a Flux architecture that supports server-side rendering and keep it in mind. That way, if you need to improve the performance of initial page loads, you have the means to do it.

Best way to handle Javascript rendering vs. Server side template [duplicate]

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.

Resources