Developing a Windows Desktop application that uses Chromium Embedded Framework for the UI frontend, but I assume this would apply equally to Electron and similar platforms as well.
The application will have multiple pages, each implemented as its own component. In a traditional SPA this would typically be implemented using Vue Router, but I assume the main benefits of Vue Router are the ability to route to the appropriate resource based on URI, parse URI query parameters, and enable the forward and back buttons with history.
Since none of these really apply to my Desktop application, I am thinking that Vue Router will bring little to the table and just add more boilerplate noise to the codebase. If I'm missing something and there is a significant benefit in Vue Router for my use case, please let me know.
Side note: I do plan on using Vuex to allow the different page components to work on the same set of state data without a lot of tedious prop/event binding.
I would still opt for vue-router, since it provides a standardized way for in-app routing in Vue apps. It is not some sort of exotic dependency you are introducing.
If your app is growing and you need things like nested routes and dynamic routing, passing props to a route, having navigation guards like ‘beforeEach’, you can just use it, without creating your own solution or rework the app to use the router. Also, another vue developer immediately understands the app routing and so do you, if you have to change something in the app after a year not working on it. And it is all well documented.
And you are developing a desktop app, which makes a few kB more or less in the bundle not a concern, I would think.
Automatic active link CSS classes
HTML history with back/forward navigation support
Nested components
etc.
Related
I have just picked up Vue and am trying to figure out the best way to structure this project.
Requirements:
A basic MPA (traditional site) with about 6 pages. This will be static info.
There will need to be a login section where customer will transmit data via form. Payment will happen here as well so will need to be secure.
My question is how should I be using Vue here? (I've already used VueCLI to scaffold out the project)
Should I:
A) use it for some components (Navbar, buttons, forms, etc) and keep structure traditional? How would i build out the User Dashboard to submit form info in this case - just as a new page?
B) or should I build this whole site as a SPA and have the new 'page' info loaded in on click? This would be easier for the login section?
One thing that may be clear on reading this is I don't understand well how the site will recognize users and deal with logins. Would this be easier if it were structured as a SPA? (more secure?)
(Also, I'm using this site to teach myself front-end development, specifically would like to learn more about building SPAs - so I realize I could use a web editor or easier solutions, but want to learn how to do a lot of this from 'scratch')
From what you've described it is entirely up to you. Both SPA or MPA would work fine and either would be totally reasonable given the requirements.
Have you worked with Vue-router before? SPAs don't need to appear as a single page to the user. They can still function as an MPA with different routes, page files, permissions, etc.
If you are hoping to use this project to teach yourself front-end web dev and know you have a particular interest in learning about SPAs, I think that is your answer.
I would go with an SPA and set up vue-router to manage your routes, and pages.
I currently learning Vue and I am building a movie database app, where users can see movies fetched from an external API and sorted by popular and upcoming.
I have to call different URLs for both categories and I was wondering if I should do that in each component or a separate, third component where all the fetched data is stored?
Does it make sense to use Vuex for a small application like this or is there another best practice? Thanks!
IMHO, Use of Vuex is not about size of application, but the structure. If you want a clean app structure, keep vue SFCs as "simple" as possible. Any logic should be in Vuex and any complex function should be in utility classes.
When you're dealing with an application (not individual components) that utilizes an API, I would recommend placing the API and data hydration into Vuex. (or rather a separate function, but initiated by vuex)
This would allow any component to have access to not only the data, but the loading status of the data. Allowing you (for example) to use something v-if="dataIsLoaded" for components that expect the data to be there, and v-else for loading indicators
There are many resources online and here on stack overflow that will guide you in this. Without knowing how big your application is right now and how big is going to grow, it is difficult to suggest whether to use Vuex or not. In any case, where you make your API calls is / should be independent of your state management.
In general API calls in Vue applications can be made safely in the created lifecycle hook of the component.
created() {}
If you are not going to reuse the data from the API in multiple components, then you can call it in the component where it is needed. If you want to want to do it in a third component, it has to be a kind of wrapper around around your components for popular and upcoming and then pass the data received as a prop to these components.
Approach 1:
MoviesWrapperComponent: Makes the API calls and passes it down to other components
PopularMoviesComponent: Receives data from MoviesWrapperComponent
UpcomingMoviesComponent: Receives data from MoviesWrapperComponent
Approach 2:
PopularMoviesComponent: makes its own API calls.
UpcomingMoviesComponent: Makes its own API calls.
How I do it, is the Ajax calls in each method as in this way it's easier to handle the promisses and the scope of the components.
I'm using the popular Axios plugin, and i'm very happy with it. https://www.npmjs.com/package/vue-axios
I wouldn't use vuex if you just need to share data between a couple of components, but you can use it if you want to learn how to work with vuex.
From an architectural point of view what is the best to separate/structure the Vuex Store into modules? I tend to create a module for each major routes when using Vue router.
When using this approach (diving modules by Views) I often occur the case that I have dependencies between the pages and Vuex modules.
The provided example of Vuex documentation is recommending a domain driven approach?
https://vuex.vuejs.org/guide/structure.html
I usually create my modules around my data rather than around the routes calling the data. The point of state management in Vuex is to allow access to data from multiple components and routes after all. So for example, if I'm querying an API for a user, I'll make a module related to that user object. Similarly, if you have a themed UI, I would create a module for switching themed elements. Or if you are using a toast notification to display success/error messages that might be a good candidate for a module.
We have a monolithic spa composed by 3 distinct "apps". Layout is divided in two parts
header: navbar containing links to apps + user information
main container: where selected app is rendered.
Everything was developed in a single repository even if every app is completely indipendent from other.
Now, we are rewriting frontend in vuejs + vuetify and need to split this monolith into indipendent projects we don't know what is the best solution to share the navbar between every app.
This are some solutions we googled:
use iframes -> usually iframes are not recomended
use ssi -> there are lack of resource and seems too complicated to set up and manage
deploy single apps as "web components"(vue-cli build -wc) -> web components created by vue-cli rely on a global VUE object and not sure this can work properly + performance could suffer
Are there some KISS patterns for our problem?
Projects like mosaic9, single-spa or similar are too much for our use case.
Thank you.
We are building a website that—to our all sorrow—has a lot of advertisements. Now we wanna use VUE to build the website, do server side rendering and hydrate the website in the client.
The problem is that the advertisements can basically do anything. Ie. change the background image, inject stuff in the dom, etc. pp.
So the the strategy we want to implement is to render the site in the server and only hydrate specific parts of the website, i.e. specific components with VUE, leaving the rest to the site to the advertisements.
Is that possible with VUE?
edit to clarify: The problem ist that if we hydrate the entire site VUE will clash with things the ads have changed in the site. That is why we want to hydrate specific components in the site only.
Late answer but perhaps the Vue Quench library offers some functionality you're looking for. This presentation from the creator details how their team runs a sports website composed of 4 smaller hydrated Vue components based on static HTML markup.
A strategy such as this allows a coexistence of both a Vue app (or multiple Vue instances) alongside the advertisement content you're required to embed.