Vue.js has a rich echo systems with several free utilities, tools and component. Particularly interesting is the list of freely available curated list of vue components "awesome-vue".
My question is how safe these components list is to use in the production use case scenarios? What precautions one must follow to use them as-is or is it better to write your own components for production use to ensure safety, security and minimize potential code breaks or defects etc.
There is no curation on this list regarding safety. All the components listed there have their own creators so it's impossible to say if they are safe to use in production or not. In case you are doing something critical with these components, it's advisable to audit the code yourself as it should be available on most cases.
Assuming the components are on npm, you can pin the version numbers of the components to always use the same component, so that way there's no risk of code breaking as the code for the certain version will always be the same.
Related
We are 3 teams:
Website front-end (React)
Website back-end (Node.js)
Native app (React Native, Node.js)
We want to share logic (e.g. Validations).
As of now I found articles on 3 ways to do so:
A NPM Package we will create for our own needs
A micro-service with endpoints who carry relevant logic
Serverless functions who carry relevant logic
Any other real-life, production suggestions?
Any other real-life, production suggestions?
Kind of - in no specific order:
You could specify the rules in a language/technology agnostic way, and then have your app load them at runtime (or be compiled in during build). The rules could then exist as a config file, or even be fetched from a remote location (a variation on your options 2 & 3).
Of course, designing a language agnostic rules engine / approach is non-trivial, and depends on what you need the rules to do (how complex, etc). You might find a pre-built open source solution that does that.
I have seen people try this, but the projects never succeeded (for unrelated reasons). One team specified the rules in an Excel sheet.
But there are trade-offs:
Performance hit - how to take language agnostic rules and be able to execute them? This will probably take some translation. Native code is almost always going to be faster and more efficient.
Higher development effort.
Added complexity - harder to debug (even if you compensate by developing more mechanisms to assist you do that - which is more development effort).
Regarding Your Options
For what it's worth, code / design-time sharing is an obvious approach, which I guess is sufficiently covered by NPM. I don't know enough about React and Node to know if they have any better ways of doing that. Normally if I have logic I want to share I'll use a component which is purpose built (lean as possible, minimal dependencies, intended to be re-used across multiple projects), and ingested in (C# / .Net) at compile/design time.
As an alternative to NPM you could look at dependency injection. This would allow you to do things like update the logic even after the app was deployed, as long as it can access where ever a newer set of rules are. So it's a bit like your option 1 (NPM, code level loading) but at runtime, and just once, and your options 2 & 3 - fetched remotely at runtime - the difference being that you're ingesting the logic not firing off questions and receiving answers (less chatty).
Service base rules are good in that they are totally separated, but the obvious trade-offs are availability and performance at runtime.
I don't see a difference in your options 2 & 3 from the stand-point of creating, managing and sharing logic. The only material impact is on whomever implements and supports that service system.
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 am recently learning Angular 6 with #ngrx/store while one of the tutorial is to use #ngrx/store for state management, however I don't understand the benefit of using #ngrx/store behind the scene.
For example, for a simple login and signup action, previously by using the service(Let's call it AuthService) we might use it to call the backend api, store "userInfo" or "token" in the AuthService, redirect user to "HOME" page and we can inject AuthService in any component where we need to get the userInfo by using DI, which simply that one file AuthService handles everything.
Now if we are using #ngrx/store, we need to define the Action/State/Reducer/Effects/Selector which probably need to write in 4 or 5 files to handle above action or event, then sometimes still we need to call backend api using service, which seems much much more complicated and redundant...
In some other scenario, I even see some page uses #ngrx/store to store the object or list of object like grid data., is that for some kind of in-memory store usage?
So back to the question, why are we using #ngrx/store over service registration store here in Angular project? I know it's for "STATE MANAGEMENT" usage, but what exactly is the "STATE MANAGEMENT"? Is that something like transaction log and When do we need it? Why would we manage it on the front end? Please feel free to share your suggestion or experience in the #ngrx/store area!
I think you should read those two posts about Ngrx store:
Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?
Ngrx Store - An Architecture Guide
If the first one explains the main issues solved by Ngrx Store, it also quote this statement from the React How-To "that seems to apply equally to original Flux, Redux, Ngrx Store or any store solution in general":
You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.
To me Ngrx store solves multiple issues. For example when you have to deal with observables and when responsability for some observable data is shared between different components. In this case store actions and reducer ensure that data modifications will always be performed "the right way".
It also provides a reliable solution for http requests caching. You will be able to store the requests and their responses, so that you could verify that the request you're making has not a stored response yet.
The second post is about what made such solutions appear in the React world with Facebook's unread message counter issue.
Concerning your solution of storing non-obvervable data in services. It works fine when you're dealing with constant data. But when several components will have to update this data you will probably encounter change detection issues and improper update issues, that you could solve with:
observer pattern with private Subject public Observable and next function
Ngrx Store
I'm almost only reading about the benefits of Ngrx and other Redux like store libraries, while the (in my opinion) costly tradeoffs seem to be brushed off with far too much ease. This is often the only reason that I see given: "The only reason not to use Ngrx is if your app is small and simple". This (I would say) is simply incomplete reasoning and not good enough.
Here are my complaints about Ngrx:
You have logic split out into several different files, which makes the code hard to read and understand. This goes against basic code cohesion and locality principles. Having to jump around to different places to read how an operation is performed is mentally taxing and can lead to cognitive overload and exhaustion.
With Ngrx you have to write a lot more code, which increases the chances of bugs. More code -> more places for bugs to appear.
An Ngrx store can become a dumping ground for all things, with no rhyme or reason. It can become a global hodge podge of stuff that no one can get a coherent overview of. It can grow and grow until no one understands it any more.
I've seen a lot of unnecessary deep object cloning in Ngrx apps, which has caused real performance issues. A particular app I was assigned to work on was taking 40 ms to persist data in the store because of deep cloning of a huge store object. This is over two lost render frames if you are trying to hit a smooth 60 fps. Every interaction felt janky because of it.
Most things that Ngrx does can be done much simpler using a basic service/facade pattern that expose observables from rxjs subjects.
Just put methods on services/facades that return observables - such a method replaces the reducer, store, and selector from Ngrx. And then put other methods on the service/facade to trigger data to be pushed on these observables - these methods replace your actions and effects from Ngrx. So instead of reducers+stores+selectors you have methods that return observables. Instead of actions+effects you have methods that produce data the the observables. Where the data comes from is up to you, you can fetch something or compute something, and then just call subject.next() with the data you want to push.
The rxjs knowledge you need in order to use ngrx will already cause you to be competent in using bare rxjs yourself anyways.
If you have several components that depend on some common data, then you still don't need ngrx, as the basic service/facade pattern explicitly handles this already.
If several services depend on common data between them, then you just make a common service between these services. You still don't need ngrx. It's services all the way down, just like it is components all the way down.
For me Ngrx doesn't look so good on the bottom line.
It is essentially a bloated and over engineered Enterprise™🏢👨💼🤮 grade Rxjs Subject, when you could have just used the good old and trusty Rxjs Subject. Listen to me kids, life is too short for unnecessary complexity. Stick to the bare necessities. The simple bare necessities. Forget about your worries and your strife.
I've been working with NgRx for over three years now. I used it on small projects, where it was handy but unnecessary and I used it in applications where it was perfect fit. And meanwhile I had a chance to work on the project which did not use it and I must say it would profit from it.
On the current project I was responsible for designing the architecture of new FE app. I was tasked to completely refactor the existing application which for the same requirements used non NgRx way and it was buggy, difficult to understand and maintain and there was no documentation. I decided to use NgRx there and I did it because of following reasons:
The application has more than one actor over the data. Server uses
the SSE to push state updates which are independent from user
actions.
At the application start we load most of available data which are
then partially updated with SSE.
Various UI elements are enabled/disabled depending on multiple
conditions which come from BE and from user decisions.
UI has multiple variations. Events from BE can change currently
visible UI elements (texts in dialogs) and even user actions might
change how UI looks and works (recurring dialog can be replaced by
snack if user clicked some button).
State of multiple UI elements must be preserved so when user leaves
the page and goes back the same content (or updated via SSE) is
visible.
As you can see the requirements does not meet the standard CRUD operations web page. Doing it the "Angular" way brought such complexity to the code that it became super hard to maintain and what's worst by the time I joined the team the last two original members were leaving without any documentation of that custom made, non NgRx solution.
Now after the year since refactoring the app to use NgRx I think I can sum up the pros and cons.
Pros:
The app is more organized. State representation is easy to read,
grouped by purpose or data origin and is simple to extend.
We got rid of many factories, facades and abstract classes which lost
their purpose. The code is lighter, and components are 'dumber', with
less hidden tricks coming from somewhere else.
Complicated state calculations are made simple using effects and
selectors and most components can be now fully functional just by
injecting the store and dispatching the actions or selecting the
needed slice of the state while handling multiple actions at once.
Because of updated app requirements we were forced to refactor the
store already and it was mostly Ctrl + C, Ctrl + V and some renaming.
Thanks to Redux Dev Tools it is easier to debug and optimize (yep
really)
This is most important - even thought our state itself is unique the
store management we are using is not. It has support, it has
documentation and it's not impossible to find solutions to some
difficult problems on the internet.
Small perk, NgRx is another technology you can put to your CV :)
Cons:
My colleagues were new to the NgRx and it took some time for them to
adapt and fully understand it.
On some occasions we introduced the issue where some actions were
dispatched multiple times and it was difficult to find the cause of
it and fix it
Our Effects are huge, that's true. They can get messy but that's what
we have pull requests for. And if this code wasn't there it would
still end up somewhere else :)
Biggest issue? Actions are differentiated by their string type. Copy
an action, forget to rename it and boom, something different is
happening than you expect, and you have no clue why.
As a conclusion I would say that in our case the NgRx was a great choice. It is demanding at first but later everything feels natural and logical. Also, when you check the requirements, you'll notice that this is a special case. I understand the voices against NgRx and in some cases I would support them but not on this project. Could we have done it using 'Angular' way? Of course, it was done this way before, but it was a mess. It was still full of boiler plate code, things happening in different places without obvious reasons and more.
Anyone who would have the chance to compare those two versions would say the NgRx version is better.
There is also a 3rd option, having data in service and using service directly in html, for instance *ngFor="let item of userService.users". So when you update userService.users in service after add or update action is automatically rendered in html, no need for any observables or events or store.
If the data in your app is used in multiple components, then some kind of service to share the data is required. There are many ways to do this.
A moderately complex app will eventually look like a front end back end structure, with the data handling done in services, exposing the data via observables to the components.
At one point you will need to write some kind of api to your data services, how to get data in and out, queries, etc. Lots of rules like immutability of the data, and well defined single paths to modify the data. Not unlike the server backend, but much quicker and responsive than the api calls.
Your api will end up looking like one of the many state management libraries that already exist. They exist to solve difficult problems. You may not need them if your app is simple.
NGRX sometimes has a lot of files and a lot of duplicate code. Currently working on a fix for this. To make generic type classes for certain NGRX state management situations that are very common inside an Angular project like pagers and object loading from back-ends
We are interested in using Odoo but we would need to modify it slightly for our use case, for instance modifying partner by adding fields, and integrating with an external system.
Is it best to fork it or to make a module with the changes in? The changes would be quite specific to our use case and existing system so it's unlikely it would be useful to anyone else as a module/app.
My thinking is that by forking it would be easier to stay up to date with Odoo - we just have to pull in changes from upstream occasionally. It seems like with a module you would end up with lots of stale code that's difficult to update because you've moved it outside the source tree.
It also seems like it would be easier to deploy because you have all the code in one place rather than two.
As from my POV and according to many years of ERP - experience, it is the best advice to implement those kind of changes always in an own module (inheriting all the required standard components) and leave the standard untouched. This applies also for very specific customizations as well as for general improvements.
This procedure provides you with the best flexibility in installing, updating, distributing and maintaining your code while not being touched when updates to the standard modules are carried out on the target systems.
You will also be able to share and move your code between dev/test/prod systems and applying a version control on it.
Please always make sure to be in line with valid license obligations applying to your code (especially when inheriting standard modules).
Hope this helps ;-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What is the difference between module vs. component design?
I'd like to share my idea about this difference.
Both component and module are used to refer to a group of functions or a part of a function. Module is more logical, for example: module Finance, module HR, module Manufacturing... in ERP system. On the other hand, component is more physical. In software, it can be a dll, ocx, exe,...
There is no criteria to measure which one is greater than the other. One component can contain list of modules, and one module also can contain many components. Components are used to model a system in technical view, and module is used to model the system in function view ( functionalities of the system)
Components and modules are too often confused with each other. They
are, however, not the same, and the implications of one, does not
necessarily hold for the other.
Modularity is the partitioning of code into modules of related
functionality. In many programming languages, a module is simply a
source file. It is common practice that if the source file grows too
big, you can split it into two or more source files, and put these
into a new directory; while a directory is often not called a module,
this kind of decomposition is still modular.
A component, on the other hand, can be composed in different ways with
other components to form different programs. That is, there is a
separate composition stage, where real people decide which components
should be used together.
I have seen component design being used to enforce some notion of hard
modularity. This approach cannot be recommended because of the rather
significant overhead of composition: the composition complexity grows
polynomial with the number of components. And the number of
components grows linearly with the number of functionality groups,
because once you get started with modularity by component
decomposition, you force yourself to create a new component whenever
you would otherwise just need a new module, because that new module
would otherwise not really belong anywhere. At a 100 components, the
composition overhead became a full-time job, and each composition
iteration would take up to a couple of weeks, despite numerous
automation efforts. This significantly impeded development.
My simplest recommendation is to stay away from components if at all
possible; well-knowing that components may sometimes be a necessity.
For instance if multiple independent organizations are involved in a
project, one component for each organization seem acceptable.
It is a matter of taste, how fine grained your decomposition into
modules should be, though everyone agrees that modularity is a good
thing.
If I know the name of a function, my editor will find it soon enough.
On the other hand, if for some reason I don't know the name of a
function (or a class for that matter), modularity becomes more
important.
I would expect the later case, to only be an issue for functionality that
you can experience from using the program, so try to make the
decomposition of your program into modules reflect an intuitive
decomposition of the behaviour of your program into areas of
functionality.
There is a reference in the «OSGi in Action» book, which, I believe, explains the differences well.
Modules vs. components
Doesn't it sound like modules and components have a lot in common? They both provide stuff to each other and consume stuff from each other. They're also packaged as independent deployment units. Couldn't these two be considered one and the same or at least be combined? Yes, they could, but components and modules serve different purposes and are somewhat orthogonal (they're not completely orthogonal, because components are made from code that can ultimately be packaged into modules).
Modules deal with code packaging and the dependencies among code. Components deal with implementing higher-level functionality and the dependencies among components. Components need their code dependencies managed, but they technically don't need a module system to do it (often it's us programmers doing it via the class path).
A good summary is that you can think of modules as dealing with static code and compile-time dependencies, whereas components deal with instances and execution-time dependencies.
— «11.1.1 What are components?», «OSGi in Action» (page 347).
If you mean module in the sense of modularity there is a definition in the IEEE Standard Glossary of Software Engineering Terminology:
"Modularity is the degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components."
And Dr. Bertrand Meyer stated five criteria for modularity:
Decomposability of the problem into sub-problems
Composability of modules to produce new systems
Understandability of a module in isolation
Continuity - small changes have localized effects
Protection - fault isolation
For digital development and UI consideration (HTML/CSS/JS), I use this approach to ensure I'm staying organized and thinking before doing. Has proven to create cleaner, more organized code which translates nicely to doing more with less.
In a typical stylesheet, I'm currently setting up like this:
/* Style Guide – Mobile First
1. =Setup
2. =Modules as independent units made up of components
3. =Components as group of reusable code containing more than one element
4. =Classes
5. =Responsive as enhancement
*/
Modules as independent units made up of components: Header, Footer, Sections, Articles, Aside, etc. A house is made up of many rooms, all with special styles and functions to create an independent whole.
Components as a group of reusable code containing more than one element: Unordered Lists, Quotes, Cards, Tables, etc.
I wrote a fuller explanation you can read here.
Hope this helps!
Component is a runtime entity (can be made up of modules), independent runnable unit
Module is a partitioned system into implementation units, independent task assignment. Modules might or might not be a component
In my view, Module and Component are all just a couple of functions and assets.
And the different between them is:
Component has business logical and module not.
For example,this text input area is just a Module, but when there was some post api called,it become a Component. you can put a module everywhere and it will work fine, but Componet just can be used in a specific page or view(coz it has a specific api call)