I have a backend rendered page (django in case it matters) which I want to soup up a little using some components from PrimeVue and a markdown editor packaged as a vue component. Right now, we have a few small animations using jquery for which we include jquery from a CDN directly into our pages. A few months ago, we needed to spice up a page using some more client side interactivity and we included vue.js via a CDN onto that page (dropping jquery) and then wrote some javascript in an index.js that we also loaded up from a CDN and got our work done. This is the current state of affairs. The page currently looks like this
<html>
....
<script src="https://cdn/vue.js"></script>
<script src="/static/index.js"></script>
The div #mainvue is where vue runs and does what it needs to.
This is where we are now.
Using plain vue is okay. Now, I'd like to throw in a few components from primevue as well as a 3rd party markdown editor that's wrapped as vue component. I want to bundle all of these as wel as plain vue itself into a single javascript bundle that I can throw onto a CDN and include into all my pages. Then my devs can do their day to day work in the index.js.
Is this a reasonable approach and if so, how do I do it? I'm not familiar with the javascript ecosystem. If not, what's the right way to solve this problem. I don't want to go all the way SPA and REST API. I just want to use a few 3rd party components and vue on a simple otherwise backend rendered page.
Since you mention you don't want to "go all the way SPA," a reasonable hybrid to is to use Vue in MPA (multi-page app) mode. This will require using a vue-cli/webpack configuration to compile your Vue components into bundles, but once you have this build pipeline, these bundles can used in individual Django templates via django-webpack-loader. Information can be passed from Django via template variables directly as Vue component properties.
Re bundling, yes you can bundle all these resources into a single JS using this method, but it's nearly as easy (and far more performant) to create one or more common bundles that represent shared logic (third party libs, invidual components, even Vue itself) and then pick and choose from among these bundles as needed on individual Django templates.
The steps to implement are a bit too involved to post directly here, but I've written a series of articles Django + Vue -- Best of Both Frontends that explains. There's also a cookiecutter for boostrapping new projects using this method. I realize you already have a site, but you can perhaps adapt the implementation there.
Good hacking!
Related
I downloaded html css template and trying to integrate in "nextjs". What is difference between "_app.js" and "document.js"? where should i use/include "css, js" files? either in "_app.js" or inside "document.js" ?
As nextJS docs specify related to _app.js:
Next.js uses the App component to initialize pages. You can override it and control the page initialization and:
Persist layouts between page changes
Keeping state when navigating pages
Custom error handling using componentDidCatch
Inject additional data into pages
Add global CSS
Next page of the docs also specify that _document.js is:
A custom Document can update the and tags used to render
a Page. This file is only rendered on the server, so event handlers
like onClick cannot be used in _document.
So basically your global css should go in App.js. However if you need to import certain CDN styles for some libraries I suppose you can do that here as well (but you should probably consider using just _app.js for this as well as it can be seen in this example)
Regarding the JS question as wikipedia states:
Next.js is an open-source web development framework created by Vercel enabling React-based web applications with server-side rendering and generating static websites.
So basically you should import React components where you need them, but I would recommend you to follow a tutorial if you need to learn more about React (There are a lot of beginner NextJS tutorials that can cover this).
I have been struggling with how to implement Angular 7 into my .NET Core 2.X project keeping the best of both frameworks without success. The main problem that I am facing is that Angular wants to control my frontend and how it receives it. By this I mean it forces you to use static templates for everything, I get the concept but for my project, this is going to generate an insane amount of templates/components or templates with a bunch of unused display elements. It makes much much more sense to have more of a generic frontend component that receives the templates from the server then handle all the binding, DI, updates etc.
I have looked at several options and questions about Dynamic Components, Dynamic TemplateURL's, Custom Elements and lots of other topics. But the problem I see with most of these answers is that none of them actually have a dynamic template, they might use Dynamic Components but the actual loaded control still has a static template in the end.
This question seems to be pointed to most
I did run across a solution that seemed to be an option but then I realized that it had to be run with the JIT Compiler. That again adds unnecessary load on the client when everything could be compiled ahead of time.
There was also one about using Angular Elements but this has its own problems apparently and really doesn't fix the issues without allot of rewiring or other workarounds to keep everything working.
The Dynamic Component Loader sounded very promising, From the Angular site it states
Component templates are not always fixed. An application may need to
load new components at runtime.
That implies that the templates may be set dynamically but at the same time, it implies that loading a new component at runtime will fix that. But the component loaded has a static template. Nowhere is the template generated or changed, or am I simply missing something?
I have looked at Angular SSR and that almost handles it but I can't seem to figure out how to go through the Controller or otherwise utilize any of the benefits of .NET Core/ASP.NET or dynamic server-generated content. It seems to just offload the compiling from the client onto the server but still uses the same static templates. Is there a way of using Node.js to render a MVC Route then send the module?
There used to be a way to set the TemplateUrl of the Component to a Route on the Server but that is now not allowed, making a lot of the answers I have found obsolete but the exact way I would like to set this up.
The only real option I have been able to figure out is using MVC to generate Dynamic Modules/Components then load them in the Angular App. Would it be feasible to compile the .cshtml view via a controller to create an HTML string that is then used to Compile an Angular Module/Component then send that out to the Client and load it into the Angular App?
I understand how to compile my View into an html string but I am not sure how to go about Compiling the Angular Module or even if this is the right idea or if there is a better way of handling this?
It seems to me that this should be a fairly easy thing to do, all the tools seem to be there but not sure how to get things working right.
I recently started with Angular (After working with .net, jquery, javascript, react) and my first interaction is directly with angular 7. The first thing I noticed was how quickly I can develop in angular, but there are a lot of files which I am not even sure about, however are generated compare to react, but the learning curve was higher in react then in Angular definitely.
If you need something really lightweight, you should definitely go for libraries then framework. react is a good option, however it's not MVC driven and you will find it very different then Angular (I am realizing it from sometime).
Other than that, if most of my code is static, I could have chosen some kind of HTML template frameworks (i.e, nunjucks) which can be pre-compiled.
For components created in .net, I don't think that is possible to have them pre-compiled in angular, as you will only create something in .net if you need those component having dynamic data.
Our Angular 2 app uses the Material Design framework. The app will end up as a locally served (serverless) web app on a piece of embedded software. For performance we have found it imperative to use non-Angular static html in certain situations due to load time for a couple places in the app.
I want our UI/UX programmer to be able to use as many of the md- prefixed components and CSS/JS animations within the static html pages. In other words I want them to be able to code the UI on a static page just as they would code it within an Angular 2 template, or as close to the same as possible.
I would also like changes or any customization that they make to the CSS or JS to be shared between the Angular 2 templates and the static html pages, as they should have the same look and feel and should look like they are part of the same app.
I know there are various ways to implement material design without Angular 2. (bootstrap, polymer, etc.) Does anyone know of a clean way that would make coding seamless between the Angular 2 and non-Angular portions of the web app?
From what I can tell, there are several implementations of material design (https://material.io/guidelines/) for various frameworks available. The following which can be used on a static html page without requiring an all-encompassing framework such as Angular 2:
https://elements.polymer-project.org/elements/paper-material
http://mdbootstrap.com/
http://materializecss.com/
...just to name a few. The one we decided on was the Polymer implementation. This is because the polymer syntax is very similar to the angular one. (both authored by google) Polymer prefixes with 'paper-' instead of 'md-' but otherwise is very similar and we can add both of these prefixes to any overrides in our .scss files which can be shared between the angular templates and the static html files when we need to override the default styles.
Although it is not ideal to manage to separate material design implementations, given that we require static html files for certain pages in our app it is an acceptable trade off.
Still interested in other solutions to this problem if anyone has any other ideas.
How to organize Vue-JS project [files and directory]: Non Javascript way?
Coming from a non-javascript background, I found Vue.js very intuitive and easy to use. My earlier experience in Javascript is with JQuery and vanilla javascript on the browser.
I created an application using Vue , Vue-components and vue router. Everything works fine.
My problem is, I have ended up writing a lot of code in a single index.html file of my project. This file contains over 10 templates that I have created and attached to different component in my app. I want to know that is there a non-javascript way to organize these templates in seperate files.
I see that there are options using webpack and browserify to modularize the project. But coming from non javascript background, I don't find them intuitive. I don't want to go node - npm way because that has its own learning curve and moreover it downloads a dozen of files and dependencies in my project which I don't understand. I am old school and more comfortable downloading the files and including them in the webpages.
So probably, you understand where I am going to. I need a solution where I could put my templates as separate files and read those files in the different components.
What I have tried :
Declaring the templates inside my components. But writing all that html inside the component is not that clean. It also, makes my JS file too huge. I am better in putting all data in the index.html instead.
Storing template as smaller chunk "homepage.html","about.html" and in my components, using $.get / $.load to read different components in ready function of the component. This works but I still have to fire an additional ajax call for each component which is not efficient.
Please refrain from suggesting the obvious node-npm [webpack and browserify] way. I know thats what is supported by Vue but this needs a learning curve and complete setup. Answer to this question would actually help other developers who hesitate going the node-npm way.
Please shout back if you need more clarifications to the question.
The options you've mentioned are your only real ones... the HTML of the template needs to be available when it's needed, so you either have to have it within your html file off the bat, or load it using AJAX or an in-browser loader like RequireJS (and this extension that allows it to load HTML https://github.com/requirejs/text).
In-file templates make sense for very small projects. As your project grows, you'll need to start using the tools that are built for this. NPM rocks and every JS package that you'll ever need can be included in your project in seconds.
I highly encourage you to try the Vue CLI
It does use node, npm, webpack and downloads dozens of files. Which you've you've explicitly asked for not to use, so let me clarify:
The Vue CLI takes care of the complexity and configures webpack for you.
You don't even have to know it's using webpack.
It's very developer friendly (it even has a built-in gui) and lowers the barrier to entry compared configuring a webpack config.
I hope you'll also find it "intuitive and easy to use".
I would like to use meteor with a bootstrap admin, i.e. a bundle including several bootstrap plugins, script and everything typically made as a kind of framework for developing a web application.
Usually those bundles comes with a lot of dependencies, such as external links for fonts, IE hacks as well as their own shipped file of bootstrap, jQuery and other stuff. If we were in a regular php-like framework it would have been fine.
But in order to make such a template be "native" on meteor, I thought to refactor it in such a way that local dependencies (script and css basically) are stored into folders and not loaded via a <script src="…"></script> tag (otherwise the local path would not be found) but I doubt it is really the best practice, this is why I do consider 3 options:
To use the project/public folder in order to store all the bundle's dependencies (as if it would have been in php for example)
I might refactor the bundle's code by removing any script or style tag aimed to import the js or css into the page and add the corresponding js file aside so that meteor will dynamically load it during at runtime
Like in option 2 but instead of using the bundle's jQuery source files I would install the official jQuery's package for meteor (if existing).
The first (1) option should be the quickest one to get something running but it would not be very meteor native. The advantage however would be to keep the code near to the original one and being able to upgrade once a new version of the bundle would be released.
The 2 other options would be much more elegant (especially the third one) but it would involve a lot of refactoring and induce the risk of introducing bugs I did not expected.
My preference for now is the first option one but I'm afraid of not seing the drawbacks of this approach. Does someone have any experience in importing manually the CSS and JS files the "old fashion way" in meteor ? What is the risk of such an approach compared to using the "place in folder to include" way of meteor ?