I'm currently building a VueJS app the will have map components in different formats on multiple pages. I'm therefore evaluating some existing components: vue-mapbox and vue-mapbox-gl (listed as mapbox-gl-vue on npmjs.com) and would like input on a choice criteria.
vue-mapbox has 37 stars on github and has peaked at about 86 downloads a week on npm.
vue-mapbox-gl has 87 stars on github and has seen a much more popular download history at around 1000 per week on npm.
Both projects seem to be under active development.
Apart from this difference in popularity, the main difference I see between the packages is vue-mapbox has adopted a more granular approach to creating sub-components (like markers and controls), whereas vue-mapbox-gl gives you a single map component and then you implement markers, clusters, controls, etc., withing the script tags of your base component. To my way of thinking, this is not really the 'vuejs way' where you create reusable components. However, vue-mapbox-gl is significantly more popular.
How would you choose? Or, would you skip component packages completely and write your own?
EDIT
Based on comments, I've updated this question.
My requirements:
An overview map that has thousands of points and supports clustering.
A per location map that displays a single point
Ability a edit a single point location and integrate geocoding
Popups on all points
Consistent styling and features across all map variants
Nuxt app with SSR, so ability to block SSR on maps.
Given that maps will appear on different kinds of pages, there will be some code reuse.
In a VueJS/Nuxt environment, what are the pros and cons of using vue-mapbox, mapbox-gl-vue, or writing from scratch?
Related
I am rewriting my monolithic architectural application into feature driven architecture in Vue.js. Since we are hiring more people to our organization, we need to be able to assign workers into different features/domains to work with.
We have created features directory where we have different domain endpoints as features. For example, “feature/medicines/active-substances”. In there we have the management of the substances; adding, creating, editing, displaying all relating brands etc.
Now our second feature is “features/hematology”. We manage patients there, related documents etc. But we need to use active substances for example filtering and creating patient treatment plans. Our problem comes now when we need to use active substances. Hematology feature should not use the services from “features/medicines/active-substances”. If I did use and edit some of the services or components from active substances feature, then it would most likely break something for that team. This is just one of the examples but there are many modules like this which need to communicate at some level.
So, my question is how to solve this problem? Do I rewrite the whole logic again into the hematology feature again which destroys clean architecture, or do I import the needed services from the active substances feature which leads to high coupling?
Since there is not a lot context on your pipelines or if you do TDD and how you handle your dependencies.
There's the downside and the upside of the monolithic apps for sure.
On my experience and now with Vitejs a fat SPA is not a big problem when it comes to have it or not a monolithic.
Maybe not a solution to your answer but an enhancement to your environment would improve code isolation and task organizaton.
The way we structure the projects is that we have a root project which houses vite configuration and autoloading other features we split to other git repositories which we then again deploy as npm packages to an internal NPM Registry at our company. For private projects I use private npm packages.
There is this feature:
Library mode at Vite eco system and it bundles your split project as an npm ready.
Then you can import exports of your split project at your root project as:
import { x, y } from '#org/features'.
Including the lazy loading features of the router in the eco system it really becomes blazing fast and manageable to have frontend monolithics which are well organized and perform efficiently.
With some basic experience you can dynamically also chose which libraries to load and import and inject or install them to Vue 3 eco system. Depending which features you heavily use.
So maybe, before ditching monolithic entirely and heading to Micro Frontends to deal with cookie, CORS, Domain, issues on every developer environment. Consider these insights, reasses and proceed.
If you choose the option suggested above, initially decide a NAMESPACE pattern, unique.
Apply use of the pattern on router modules exported by feature packages.
Apply use of the pattern on store modules exported by feature packages.
Namespaces save you some time and provide anchor points which you can debug issues arising from different packages and isolate user access based on namespaces they have access to e.x: state: user.access["DASHBOARD_READ", "TASKS_WRITE"] then you can create also a middleware to your vue router to perform checks if user can reach or not them at the very basic or use casl to grant access to user by iterating their access by backend to their session etc.
Also these practices are testable both unit and e2e. We use them actively at enterprise grade. No issues with speed, performance or organizaton. Each feature or group of features has/have its own repo their issues meet their respective authors and they have their own tests to pass.
I am refactoring my first pass Vue dashboard application, which uses vue-chartjs to access chart.js.
As part of doing this, I am creating a set of wrapper components that encapsulate more functionality than just the chart itself, e.g. titles, dialogs, measures etc. In doing this, I am finding that how vue-chartjs adds complexity to my task for multiple reasons, e.g. the structure of renderChart props doesn't match the parameters of chartjs itself. Also, vue-chartjs has its own unique capabilities that add a layer of complexity to using chartjs.
I assume there are other complexities that are reduced by using vue-chartjs, but... my question is:
Do experienced Vue developers use vue-chartjs to access chart.js? Or do you go direct to chart.js? My first pass approach was derived from a tutorial, and I didn't question it at the time. Now that I'm doing more complex things, vue-chartjs is getting in my way as I try to simplify and minimize data marshaling.
For now I am working around these issues, but if it is reasonable to create my own wrappers rather than add an unnecessary level through vue-charts, I would like to try that. But I don't want to venture into this without first asking for feedback from other dashboard folks who have done it!
Thanks for any advice on this.
Anecdotally speaking, I've found in some code reviews less experienced devs tend to rely on vue-**** wrapper libraries even when there is little (or even no) benefit. Adding additional libraries increases exposure to more dependencies, each of which theoretically carries a potential for security vulnerability. I've also seen the opposite, where the functionality is re-invented when a vue library is available and would save significant amount of time and have a more robust component(like including aria fields or thoroughly tested with various browsers). The tl;dr; being, I take is on a case by case basis.
I agree with #Daniel. I can give another example where I used vue-popper wrapper package. The component itself is not bad, it's well done, however, it uses the previous major version of popper.js which lacks good new features and improvements. For this reason I created later my own implementation of vue popper with the latest version.
I'm want to create a large scale mobile app in react-native, after some research and read the various articles from medium and other websites I'm total confused what architecture i'll used to make my application better or developer friendly architecture. Please help me to find the best react-native architecture to build large scale application. Thanks in advance!!
There isn't a single possibility of how you want to structure your files. There are various recommendations on how do to so, but they basically boil down to making sure to have a logical file structure, trying to group files that "work together" in a folder, and trying not to keep files that have nothing to do with each other in the same one. Use the base folder to keep global project files, and the deeper in the navigation stack, the deeper the files should be (If there is only one path through which they can be accessed). Name reducers/sagas/etc accordingly, and you should be well on your way. But most importantly, there is no correct way, only the one that makes the most sense for you. If it seems cluttered, you can always reorganize, so don't worry too much now about scaling, and focus on starting your application (But make sure it isn't a complete mess!).
for sure, there're different ways to organize your app. In our team, we worked closely with our mobile department to create an architecture for our current React Native projects.
The key point here is to split responsibilities across special components dedicated to doing the only one thing. We divided our components into several layers to achieve a better understanding of what part of business logic should go where:
Screens
Containers
CombineViews
Views
In the article, we described every step with code snippets as examples. Take a look.
The approach of arranging business logic helps to clearly know what goes where not polluting containers or simple views with state and methods. Hope it will help you in your future projects!
Clean architecture in very trendy at the moment. Maybe you can check this out : https://github.com/eduardomoroni/react-clean-architecture
Clean architecture let you separate concern of your app.
Our front-end team is presently working on a Reporting application with the following features:
Dashboards
Portfolio Analysis Tool (search form that returns grid-based results)
Automated Reports page
We've decided to architect the above using VueJS with the Webpack boilerplate (via Vue-Cli) and are trying to design to have common components:
A report component
Has title, description, type (grid, visualization, etc.) and some setting parameters
A report list component
Has a title and an array of report components as its properties
A dashboard that has an array of report list components arranged in a grid
Some requirements
A dashboard component can have 4 or more report list components, each with multiple reports that can be selected for view by the user from a report list select menu. Each report component can have one or more setting parameters that the user can manipulate and submit to re-render the report. A report can be a grid (ag-grid in our case) or a visualization-based report. Lastly, there is also authentication via Auth0.
Questions
Does it make sense to use Vuex to manage state for all our components and related interactions?
Does it sound like the application is a good use-case for Vuex?
If so, why? Is it better than using component to component communication via the built in Vue mechanisms (for parent-child, sibling-sibling components)?
Thank you in advance for helping us make a decision.
Vuex is useful when you have multiple components that need the same state. In your case, you're displaying reports in lots of different places and formats. This is a great use case for Vuex in my opinion.
Now, i don't know if your team is familiar with Vue, but passing data via props is a PITA. Especially if the components that need the data are spread far away in the component hierarchy, and deeply nested, which they usually are. Anyone who's been thru the gauntlet of passing props and emitting events up multiple levels will tell you that.
With Vuex, it's a single function call to get your data, from ANYWHERE in the component hierachy. It's a breath of fresh air.
I voted to close this question, because the answer is highly opinionated.
I've built multiple projects with Vue, some with dozens of components and many multiple thousands of lines of code. I've never once felt the level of complexity rose to the level that I needed Vuex.
You've described an application with half a dozen components.
I've definitely abstracted my logic out into custom objects, but that's just javascript.
YMMV.
For the last year, I have delivered several relatively simple single-page apps, essentially almost-alike mortgage and financing calculators, to various customers. These have either been the sole focus of a page, or sidebar apps beside some main content. Since these apps differ by very little else than styling, layout, and a few customer specific parameters, it would mean a high ROI if these SPAs could be consolidated into some kind of library.
How one would go about in doing it in practice is a bit more unclear. What are the key points to consider and/or avoid when creating a library of pre-made interactive components?
They need to
be custom-styled per customer (custom widths, heights, fonts, etc)
not clash with other page elements
... ?
It seems unwise (inflexible) to pre-render html and inline css on the server side, and maybe some kind of half-baked JSON representation would be more appropriate, where the actual assembly would be controlled by some javascript, and styling would be done on the client based on some default stylesheet we provide. Or maybe somehow use GWT (we are a Java shop) to create the widgets.
I am out of my depths here so input would be most welcome.
in this case, possibly a better way to think of this is not creating a library, but creating a "calculator" application (widget) that can be configured for different kinds of calculations and to be themeable
So your focus is on how to create it so you can configure it for different functionality.