I'm working in VSCode with some Vue components that I copy/paste into my company's CMS (long story). I have a single file for each component (HTML with inline CSS and some Vue and Axios) that appears on the final webpage which has dependencies in the head. There's often trial and error to test my endpoints, text formatting, etc. so I would like to test before deploying to my site with a tool like VSCode. Is there a way to tell VSCode to load the Vue and Axios frameworks rather than include them at the top of each component file? I can test each piece individually but not together.
As you can see, I may also just be missing some major concepts in web development and/or VSCode features.
Related
I have a project where I use deck.gl to create web maps. It works fine, however, I need the functionality of drawing polygons and, for that, the deck.gl documentation tells me to use nebula.gl. The sample of the functionality that I need can be found here: https://codesandbox.io/s/deckgl-and-nebulagl-editablegeojsonlayer-no-react-p9yrs?file=/app.js
The problem that I have is that on the nebula.gl documentation there's no library compiled to be used on a <script> tag. They only work with the library installed through npm or yarn, then the only way I managed to make it work so far was by compiling the entire project with webpack... In my specific case, I'd like to avoid compiling the entire project and I'd prefer using a compiled js file with the <script> tag.
Is it possible to compile npm libraries with webpack into a single js file? Just so I can use this nebula.gl library with a <script> tag on my webpage? Or am I misinterpreting the way I should be using webpack?
I would like to ask what is the best approach to include and reuse Vue components that are written in .vue files (SFC), into existing web pages.
For example lets say there is already an SPA project and also an ASP Core project. I would like to reuse my ~/SPA Dir/components/*.vue into my Razor pages or just plain HTML pages. To be more specific the web pages are using Vue through the CDN js file.
In most Vue tutorials it is often mentioned how Vue is used to create SPAs or it can be used in already existing web pages. And there is also emphasis on the reusability of its' components. But it seems very frustrating and complex to follow those guidelines with often lacking and unclear guides.
From my research I realize that there must be an intermediate build process that will produce js files form the vue files. And also the need of tools like vue-loader and webpack. But still I could not find something straight to the point.
Is there a more straightforward approach or what is the most common approach to the above-mentioned scenario.
(Vue version: 3)
Thank you
Maybe try this SFC loader: https://github.com/FranckFreiburger/vue3-sfc-loader
I use it on my PHP server, where I have my .vue components and I need to compile them as .js.
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.
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.