Search posts, tags, users, and pages
What's your front-end? node.js is back-end and as such has no mechanism for realtime making a modal client-side unless you're sending that output client-side somewhere. If that's a dynamic modal that means client-side AJAX, if it's on-load you'd just be outputting it and then setting up some form of control to it.
Either way it's not something node.js by itself can even do. Modals are client/render side so what's your client/render?
you are absolutely right there are many ways to make the popup depending on the frontend that is used: angular, react/redux however some nice plugins like sweetalert2 does exists to help beginner integrate it faster. There are tons of them if you look for "nodejs popup". However on the ajax part which is what I was talking about, I do recommend to use connect-flash or socket.io to pass the message... of course again there are plenty of nodejs message broker to chose from, but for a beginner those are the easiest to understand in my opinion.
Nicolas Cloutier Thing is this doesn't even sound like a job for a push notification since this comes across as a simple AJAX mail send, one that should PROBABLY also be written FIRST to work scripting off.
But then for something like a mail/contact form that's EXACTLY how I write my pages, for client-side scripting off functionality FIRST and THEN enhance it with scripting... That way I'm not telling large swaths of users to go f* themselves as is so popular amongst vue/angular/react and other 'framework' fanboys.
AKA the type of scripted garbage I'm always ripping out of the websites for clients who are in court for accessibility violations!
... which is why for the scripted enhancement I would be simply serialize the form, send it server-side via AJAX, the 200 handler recieving from the server JUST the error/success messages with NO markup slopped into it, generating DOM elements for the modal (as node objects, NOT markup), attaching them directly to the BODY element, with the scripted button for closure of the message coded as
closeAnchor.onclick = function(e) {
document.body.removeChild(e.currentTarget.parentNode);
}
No dumbass 'framework' BS needed. All style for the modal being in the (singular) external stylesheet for the appropriate media target. (since style/presentation has little if any business in your huffing markup or scripting!)
my front bootstrap and ejs view engine
Atul kumar [i]Well there's your problem.[/i]
Apologies but I'm going to be very frank with you -- If you are using bootstrap by CHOICE you probably don't know enough about HTML or CSS to be coding the front end. PARTICULARLY given what it is you're trying to do. It is a bloated wreck that prevents you from doing anything 'properly' and there's a reason I call it "bootcrap" and tell people to go find a stick to scrape it off with before tracking it all over a website's carpets. The ONLY thing you can learn from it is how NOT to use HTML or CSS, which is why you likely are creating two to ten times the HTML needed to even do the job. In particular the use of "JS for nothing", "endless pointless classes for nothing", and "presentational classes" piss on good practices and the entire reason HTML and CSS were even created.
IF this is for a website (and not a standalone application for something like nw.js, electron, UWP, etc) "Embedded JavaScript Views" being similarly flawed in that they work via innerHTML style methodology (bloated, slow), promotes client side rendering even when not appropriate (accessibility violation) and a host of other problems. Most likely they have duped you into bad / broken techniques that are why you're having issues doing what -- for those of us who embrace separation of concerns and progressive enhancement -- should be a relatively simple task.
I would suggest kicking all that to the curb and to focus on making a minimalistic accessible scriptless front-end FIRST without the ignorant TRASH that are frameworks, and then enhance it with scripting where/as needed/desired. Emphasis on 'needed' over 'desired'.
I mean again, I'd be writing the form to work without scripting first (assuming this is a contact form, which the use of e-mail suggests it is) so it works scripting off with a normal pageload FIRST. Then I would enhance it with an AJAX submit that on 200 would create the modal on the DOM, (using the bloody DOM and none of that innerHTML rubbish) creating a button that removes it's parent from the DOM 'onclick', and let CSS do all the heavy lifting for the appearance. I mean at most we're talking an outer DIV for 'lightbox' style dimming of the page, inner DIV for the centered content, the close button, an H2 for the title, and then the content itself.
This isn't the type of stuff to waste that framework bloat on. NOT that I generally see much reason to EVER waste frameworks on the front-end. Waste of code, waste of time, and riddled with bad practices that make you work harder, not smarter! All those things are teaching you is how NOT to use web technologies, violate accessibility norms, and create more code than you'd write without them, at the same time starting out with more code than you should even NEED.
I'll try to revisit this later to show you a simple example of what I mean. I will likely use a small "DOM Make" helper function (under 1k of code) to help out and not worry about legacy IE events in it, but it should give you an idea of what I'm talking about.