You have destroyed JavaScript.

Previous

In the past, we wrote some really terrible code in a very fashionable way on the page, which brought us great trouble. Maybe many people are still doing this, but they won't read this blog, and we can pretend they don't exist.

The great/amazing/surprising thing about JS is that nobody wants to approach it, and in those large organizations, they just want to stay in their own small world, it is injected by various abstraction layers and XML frameworks.

This is for companies like me who want to support them, but they don't want to endure the Terrible "best practices" composed of N layers (and they don't want non-DBA people to be moved to the database due to performance concerns.

Better yet, when these performance problems occur, by writing a front-end JS code, we can turn to security. We can pretend that these performance problems do not exist, although the background code is very bad, but it can give users a good experience.

JS has reached its peak

This is even better when jQuery appears. It can closely connect reusable jQuery plug-ins. When NPM was launched, we began to use a semi-automatic module system to manage these self-contained widgets, and we finally reached the peak of JS.

Since these modules and their combinations are independent functions and widgets, I imagine a future where I can work with a good code library and a great UI team. Maybe we can slowly regain control of the code base from these enterprise-level beans, Orm, various abstract factories, methods, and patterns.

We have some more meaningful things to do, write excellent code and build excellent frameworks, and free us from the heavy enterprise frameworks.

You ruined it.

I am still using JS, but recently I am mainly using Erlang to create video stream/encoding systems. Now I have not written them into a blog, but basically, my background is very sexy, and my foreground is also sexy (facebook's React + NPM fills the gap ). Some of the things I found on Stackoverflow have recreated all the previous days of suffering. What makes me frightened is that it spreads at the front end like a sexually transmitted disease, and the link is here:

Angular. js: Server vs Provider vs Factory?

Well, it's not too bad, but let's take a look at the answer with the highest voting rate (well, it's not the answer at the time of this article) and observe it at the same time, obviously there are some very satisfied users:

Oh! Thank you for your explanation. You make it easy to understand. Great !!

If I am kind, I will say that this comment is ironic, and the whole thing is a good example of the "Pow rule", but after reading the comment, I think this is not the case, I did not frown.

Therefore, the first thing we see is the reference of the strange Angular document, as shown below:

Angular "service" is a singleton object created by "Service Factory. These service factories are functions, and they are also created by the "service provider. "These service providers are constructors ". During instantiation, they must contain an attribute named $ get, which is the key to service factory functions.

What is this TM? I understand this as follows: "To write the Hello World Program, you must first create a hello world Service to create a hello world Factory to create a hello world application, in this way, you can output hello world on the screen ".

What ?? Am I reading a thesis? This is really messy.

No, you are not reading the paper. Obviously you are reading the angular document.

If this is a paper, it will try to present solutions to some problems, rather than making up answers to the questions that have been fabricated (in fact, this is not true because scholars live in their world ).

Most Angular creation scenarios may be fabricated, because this is the only reason we actually need all these factories, proxies, and services. The code and instructions we will use come from the illusion and are hard to believe. This is not a joke.

Services, factories, and providers can be the same.

What? Of course not. They only have functions that return values. Let's continue to follow this crazy document to see what it will become.

As a prerequisite, we get an example of "Car instantiation.

You cannot implement a service (Singleton) because it cannot be instantiated.

To prove the existence of the provider, because

To instantiate an instance, you need a Factory or provider ).

No! Oh, my God.

var car = new Car({ cylinders: 4 })

The strange keyword "new. We have been repeating this parameter in enterprise-level applications and seeing it come out again has really humiliated me.

Provider can help you configure applications

Of course, if we need to configure the application, we can configure it through (Provider. But how do we configure the configuration programs that configure the application?

I like the following code. It almost repeats itself. It is even funny without comments.

app.service('CarService', function () {    this.dealer = "Bad";    this.numCylinder = 4;}); app.factory('CarFactory', function () {    return function (numCylinder) {        this.dealer = "Bad";        this.numCylinder = numCylinder    };}); app.provider('CarProvider', function () {    this.dealerName = 'Bad';    this.$get = function () {        return function (numCylinder) {            this.numCylinder = numCylinder;            this.dealer = this.dealerName;        }    };    this.setDealerName = function (str) {        this.dealerName = str;    }});

What we need to do to configure it is

app.config(function (CarProviderProvider) {    CarProviderProvider.setDealerName('Good');});

Hey, this is just a configuration-no code needs to be changed !!

I would rather write a piece of the same native JS to enrich myself. The above example allows me to find a ground hole and hit the wall with my head.

Here is a tip. If you find yourself asking the same question. If you find yourself asking a question like this, you will be asked if you have done something wrong.

There is no shame for doing wrong. It's okay-we all make mistakes, but given the current nonsense track, we are far away from our previous ideas and we will become Angular consultants, they also offered Angular expensive training courses to our students. Good-You fell in love with it.

What are you doing?

We have something beautiful, and you ruined it. We have a way out of the absurd Enterprise Edition, and you don't want to learn how to play with the code, you just need to let these providers/Factory take a break and do things well (don't study ).

You guys. I'm going home.

It's okay. Actually, I won't do anything enterprise-level. I will present my questions and answers to my colleagues. We all think it is funny to give you, because it is so silly. But do you know? When you stop digging this hole, you will find how deep it looks. I will stand out and laugh at you loudly, because it is still your own mistake.

I started to think for myself, and it was not too late to make up for myself and I learned to write some practical code. The information is there and you can do it. If you need to master Factory, Factory Provider, and Service Provider (various modes, frameworks, and services), then realize that the world does not need your code, and then find a job you are actually working on. Do not harm the rest of us.

Original codeofrob.com