For some strange reason Angular JS has its own module system that is neither AMD nor CommonJS.
I have many existing modules in AMD format. I would like to use them in an Angular app.
I would like to avoid rewriting any AMD modules. If possible, I would also like to avoid using Angular's own module system.
Is it possible to use AMD modules when using Angular? is it possible to avoid Angular's custom module system?
You do need to define Angular components in the "Angular way" (ex. angular.module('yourApp').directive('someDirective', ...)), but you can certainly use AMD both for wrapping Angular components and for pulling in non-Angular components to Angular. Check out this seed project.
You cannot replace Angular's module definitions with AMD defines. You have to wrap your Angular code in AMD defines for now.
Another thing to note is there is no real way to "lazy load" modules at the moment. You'll have to eventually require all the angular modules you're going to use in your application in your main angular module definition, so the benefits of using AMD is limited for now.
The dev team says they'll support lazy loading at some future point, which is the only reason to wrap your files in AMD now.
Related
I'm learning Vue, and it's ecosystem, and now I read about nuxt.js.
As I understand, this is tool which help us to build Vue apps, but don't we do the same with vite.js?
What's the difference between them?
Vite is a build tool like Webpack, that will basically allow you to work locally on your app and build it for production. It will also bring to the table various loaders, Hot Module Replacement capabilities, environment variables, assets managements etc.
Nuxt is totally unrelated to all of this. It is comparable to Gatsby/Next/Vitepress for a React/Svelte equivalent.
It's goal is to provide more capabilities to VueJS. For example, Vue can only be run as an SPA, meaning that you will not get any kind of indexing with search engines, while Nuxt do have SSR and SSG modes that will allow your websites to be efficiently crawled.
It also brings a lot of Developer Experience niceties: auto import of the composition API, of the components, simple routing, huge ecosystem thanks to all of Nuxt's modules, simpler configuration etc...
It's more like VueJS apps on steroids basically!
Also, latest version of Nuxt (v3) works with Vite out of the box. So, both of them are complementary because you need a build tool to work nowadays in the JS ecosystem + you get more features than just VueJS.
There are tools like vite-plugin-ssr and vitesse (created by one Nuxt's core maintainer btw) who can solve the basic needs of statically generating some routes/etc but it's not as powerful, have smaller communities around it and is overall moving a bit slower.
Trusting people who are behind Nuxt/Vite is also an important aspect, and most of them are well known in the community + are serious daily maintainers!
I'm maintaining a library (MyLib) published on npm that is a vuejs plugin. When I started this library, vuejs was at major version 2.x.x. vuejs now has a new major version 3.x.x that changed how plugins work.
Both 2.x.x and 3.x.x versions of vuejs are supported and will be for a while longer. I want my plugin library (currently version 5.x.x) to be available and supported for both.
Options I've seen or considered so far:
Have 5.x.x as the last version that supports vuejs#2 and 6.x.x and above for vuejs#3.
Easy enough
Doesn't allow me to release a new version with breaking changes that supports vuejs#2 ever if I follow semver rules.
Create a version 6.x.x of my library that supports both versions of vuejs.
Potentially possible, depending on the specifics.
Makes my library bloated because it needs to support both versions of vuejs and have (flaky) runtime version detection to choose the right code path.
Publish a separate library (e.g. MyLib-v2) that supports vuejs#3. Can possibly use a scoped package, but that would force users of 5.x.x of my library to change their dependency name with very poor discoverability.
Not sure how to manage this in a single repo. Monorepo?
Clunky, higher overhead
Is there a better way, or at least a not-awful way of managing publishing my library in this seemingly common scenario?
Use vue-demi. It lets you publish for both vue2 and vue3 in the same project. When using vue2, you have will access to the composition api as well.
https://github.com/vueuse/vue-demi
From the read me:
Vue Demi (half in French) is a developing utility
allows you to write Universal Vue Libraries for Vue 2 & 3
Hey i search a powerful web framework with some specific features :
VueJS support (single file / template)
ServerSideRendering
Easy deployment (with Now, Netlify, etc..)
Powerful dynamic routes management
Why not Nuxt.Js
Because Nuxt does not support dynamic routes when the app is generated (it does not define routes automatically)
Use vue-cli-3 and generate a project with all the bells and whistles (vuex, vue-router, typescript, SPA, unit testing, etc). Then add Vuetify or another similiar Material Design framework to spruce up the UI.
Of course this is opinion based and your question will most likely get pulled down soon :)
I'd like to integrate VueJS through WebPack in one of my custom Odoo modules, and have it start up automatically when I launch Odoo-bin.
Does anyone have a solution?
Is it even possible?
I know you can include VueJS as a simple .JS file in the module's template, but that means I can't use the .vue components supported by WebPack.
I also read that Odoo has its own JS framework, but I couldn't find good tutorials/documentation for it.
EDIT: To anyone that might be wondering how I solved this, here's what I did:
I initialized a package.json file in the root of my Odoo folder using npm init. I added a start script to the package that launches webpack and bundles all vue components in myAddons folder (where I store my custom modules), then launches Odoo through the python odoo-bin ... command. All that's left is to use npm start to start it all up.
This way, the vue components get bundled into single JS files, that I then add to the templates of my modules. This has a small inconvenient in that the first bundle has to be done manually in order to know which JS files need to be imported to the templates. Also, i'm still trying to figure out how to bundle the components of every single module separately. Will update this once I find a proper way to do it. ...Hopefully.
By default, odoo frontend part is heavily built upon backbone, jquery, underscore. If you want to use any other JS library, you have to make sure the compatibility in between them. The odoo backend parts of JS functionalities are written under web module can be found in odoo/addons/web/static/src/js directory in odoo community codes. The ecommerce/website part is under website* modules.
Along with the fact that the Odoo JS API documentation is basically non-existent (as of the time I am posting this) .. I would add the fact that its going to be like working with a moving target compared to calling Odoo's JSON-RPC API directly since their JSON-RPC API changes very little over different versions of Odoo.
Moreover, making JSON-RPC API calls with Axios is extremely simple. So just go directly to the server's JSON-RPC API from your Vue project.
This is what I am doing with at odooinvue.org which is basically a Vue project that uses Odoo in the back-end. That project is designed specifically as a resource for Vue developers that are trying to use Odoo in the back-end but have difficulty because they are new to Odoo development.
I suggest trying #StartupGuy's odooinvue, which is really nice.
With Odoo 14 they created a new modern frontend framework: Owl framework.
I have not tried it myself.
Can any Typescript experts clarify when and why you would choose AMD vs Common JS for module creation when using Typescript?
AMD is used in the browser (e.g RequireJS) : reason is it allows parallel download of files as network latency is a major bottleneck.
CommonJS is used in the server (e.g. nodejs) where files can be read from disk upfront, but you don't want to read a file till you try to use the code it contains.
Here is a video on the subject that further explains this : http://www.youtube.com/watch?v=KDrWLMUY0R0
Are you using require.js? Use AMD
Are you using node.js? Use CommonJS
Don't know what those are? Not using either of them? Don't use external modules.