Bad advice from the creators of the Yandex.Maps API. How to make everything so bad

If chasing you
Too many people
Question them in detail
What are they upset about?
Try to console everyone.
Give everyone advice,
But at the same time reduce the speed
Absolutely no good.
G. Oster

Today is a wonderful spring day. And not only because it is spring and very soon someone will have to go to the country to dig potatoes. And because today version 2.1 of the Yandex.Map API ceases to be a beta version and becomes the main one .

We have completely updated the documentation for this event, added new examples to the sandbox and wrote this article. This time we decided not to talk only about version 2.1, since we already talked enough about it during the beta launch. Let's talk about using the Yandex.Maps API as a whole.

API development is a very specific area of ​​programming. API needs and skills are superimposed on any idea of ​​the designer and developer. The main feedback that we receive is messages from users in our club . They send examples of sites with Yandex.Maps, bug reports and recommendations for improving our product. We see how the API looks in combat conditions, and we shake on a mustache.
')
Some things often do wrong. Today I want to talk about them. All the tips you read are bad. If you realize that you are following some of the recommendations in this article, it's okay - it's never too late to make your project a little better. So, Irony mode ON.

Do not read the user agreement.

The centuries-old experience of using Windows has taught us something. We are not even trying to read user agreements. We boldly say: “I agree with everything” - and we think that karmic retribution will never overtake us, - “Are they fools, are you? To go from my silicone valley to Gus Crystal, to forbid me to use my pirated Windows? ”
If you use the Yandex.Map API, you should follow the same strategy.

Because if you read the user agreement , you can understand that it is illegal to implement your cool idea on the API. For example, you will not be able to monitor the transport or use the API in the admin panel for 1C. Or worse.

Therefore, before starting work, give yourself an installation - if you have not read the agreement, you are not aware of the restrictions in principle and the world of cartography is limitless for you. Of course, there is a minus in this - the API can be banned on your site, if a violation is detected. But, as you know, problems need to be addressed as they are received, so we calmly move on.

In general, the ideal option is to make a website, give it to the customer, get honestly earned wages and forget about it forever. If the amount of the fee was large, it is recommended to change the place of residence. Still, money spoils people.

Avoid reading any documentation.

As you know, good code does not need comments. Similarly, a good API does not need documentation. In general, any library or module should be intuitive, and the ideal API should not require programming skills. Therefore, if you want to see examples in our sandbox, or read something about the capabilities of the API in the manual, or especially look into the directory (!) - Fight the rush. The right strategy is to randomly choose one example (preferably the least detailed) and listen to the call of the heart — it will tell you how to write.

So, where it is not necessary to look before starting the development of the application:

• Developer's Guide
• Sandbox examples
• Software Interface Reference

Don't think about knowing javascript

As you know, a JavaScript programmer is not a programmer, but a coder. You should never be bewildered by this idea that the API you want to use is written in JavaScript. Studying the constructions of this language (if it can be said at all), you risk forgetting something important from another language, get confused, and everything will go to ashes.

The ideal option is to print JavaScript constructs using PHP. I will give an example:

<?php foreach($maps as $map): ?> myPlacemark = new ymaps.Placemark(["<?php echo $map['lantitude']; ?>" ,"<?php echo $map['longitude']; ?>" ]); myMap.geoObjects.add(myPlacemark); <?php endforeach;?> 

See how elegantly we managed without JavaScript!

This approach will allow you to avoid many unpleasant consequences.

• Your application will be slow enough to give the user time to think about the meaning of life.
• Your code will not require obfuscation, as it is rather confused from the very beginning.
• The page code will not be cached by the browser, but will be re-generated each time on the server.

Sadly, many programmers are still trying to go against the system. They write code in clean, well-structured JavaScript. Load data in batches at the same URL, clogging up the browser’s cache. As a result, their applications run fast, users take it for granted and do not even look at other sites. Think about the younger generation - stop making websites on which students spend their youth, free humanity from Internet addiction!

A book that is not worth reading if you decide to develop an application in JavaScript:

Avoid code structuring

If you are planning to do something a little more complicated than a location map, you might think of the architecture of your site. You might even want to select components in code, create classes, or break code into functions.

This is not worth doing for several reasons:

• Code broken into modules is difficult to read, because commands are not out of order.
• The development of architecture takes a lot of time.
• The application that uses the card, just unworthy of your time and attention. Point.

Things to avoid when developing an application that uses maps:

• No need to break the code into classes or functions.
• You should not use modular systems, you do not need any RequireJS.
• There is no need to separate the code and data into different files - if there are many files, they are easily confused.

Unfortunately, we have examples that, in spite of everything, use these approaches. You can see and appreciate their absurdity in the sandbox .

 //   . ymaps.modules.define('CustomModule', function (provide) { var CustomModule = function (defValue) { this.field = defValue; }; provide(CustomModule); }); //  . ymaps.modules.require(['CustomModule']) .spread( function (CustomModule) { // ... }, this ); 

In version 2.1, the API developers literally set traps by opening a modular system that is used in the API. Now a weak-minded developer can not sustain and break his code into modules. Take heart.

Books that could prevent you from writing the perfect code were written by cunning people. Their value system is turned upside down. The enemy must be known in person, here are some of the potentially dangerous editions:

Prepare everything in advance

If you plan to show a large number of objects on the map, you need to decide at what point to download data from the server to the client. The only correct way is to load the data immediately and preferably before loading the content of the page on which the map is shown. Think yourself - if not now, when? A person can turn off the Internet and then wept our marks. Not all programmers understand this simple truth and are still trying to load data on demand.

Here is a sad example showing how to load data into a balun tag on demand. Here is another sad example showing how to create a map on demand. And why only these developers do not uchudyat ...

Download with stock

The API is a lot of code, broken into modules and packages. After developing your site, you need to solve another important question: what API code to connect to your site?

There will not be superfluous to recall the cases when you sent a friend for a jar of cola, and he brought one. Exactly the same rule works for loading code. It is better to download the entire API code entirely - you never know what will come in handy for you. In version 2.0, developers created packages that a user may accidentally start using if he copies the example from the sandbox without thinking.



How to avoid such errors? When using version 2.0, any combination of loadable modules should be changed to package.full. With this approach, the user will receive a lot more code, which is good.

In version 2.1, developers, unfortunately, noticed that people do not lend themselves to provocations and load the API entirely. Therefore, in version 2.1, all packages were canceled, and package.full is now broken into parts that are loaded asynchronously as needed.
Instead of packages, you can now connect the single modules that you want to use. Generally without any reserve.



Programming is becoming increasingly difficult.

Add controls

The user is always happy when there are buttons on the map. Who doesn't like buttons? Buttons love everything! You can copy the example from the sandbox for version 2.0, which demonstrates the work of all available controls, and add the code to your site as is.



An experienced user may notice that not all controls are represented on this map. The careless programmers forgot to add a second scale control and search control to the map. By the way, earlier this example contained two scale controls at once. Therefore, we periodically find sites on which everything works as it should - on the map there is everything you need: a large control, and a small one. Why it took to make the example worse remains a mystery to this day.

Version 2.1 again tripped us. It has fewer controls (the villains have cut a mini-map), they are installed on the map by default and on a small map they collapse to small sizes.



See for yourself - the buttons are small, they are small. The map is generally as naked! In general, 2.1 is generally better not to use.

Show the user how weak his browser is.

If you need to show hundreds or even thousands of objects on the map, feel free to go into battle. Create tags and bravely put them on the map in full. With a sufficient number of tags, you will immediately show the user who is the boss in the world - a person or a browser. Because with a large number of tags (100 for IE, 500 for all others), the browser will grumble and freeze for an indefinite period. It serves him right.

Developers trying to hide browser imperfections mask their flaws in very sophisticated ways:

• Use clustering objects. We have devoted a lot of examples and even an entire article to this ingenious reception.
• Use active area technology. Despite the complexity of development, it removes any restrictions on the number of displayed objects. You can evaluate the cunning of the plan by reading the developer ’s guide or by looking at the sandboxed example .

Do not try to save requests to the geocoder.

Very often, users are faced with what task. They have a list of addresses of shops, pharmacies, attractions and more. All these addresses need to be shown on the map. The task is solved simply - you need to take all the addresses, send them to the client side, and simply geocode the addresses to the coordinates of the marks on the client.

An unprepared reader may ask, “Is it correct that the set of tags is the same for us, and is it geocoded every time every time my application is called for each user again?”. We answer this question directly: "Do not worry." Yandex servers are sufficiently fault tolerant and will withstand everything. The only catch is that with a large number of requests from your site you can exceed the limit of 25,000 requests for geocoding and your site will be banned. But we have already covered this problem above, so we will not clutter our heads over trifles.

Developers who have not read this article and do not believe in the power of Yandex servers have come up with geocoding data on the server. And one of our employees even wrote a module for server geocoding on node.js. This is a section in the developer’s manual.



And it was not too lazy ...

Do not take the bread from the technical support service

At some point, you may feel a strange, overwhelming desire to communicate with the Yandex.Maps API technical support service. This event should be approached seriously, and not anyhow.

Try not to load technical support with unnecessary details. An ideal bug report consists of five words - “everything is broken, nothing works.” In general, our technical support service has already cut these five keywords into one long time ago - “all-over-all are not working”. And now we have a term in which both support and developers instantly understand the essence of things.

Here is a good example of addressing a club:



The developer at the sight of this message instantly understands that all his work - ashes. The universe emerged from the big bang, expands and is about to collapse. Everything is lost. Nothing works.

Things to avoid when contacting tech support or club:

• Detailed description of the problem.
• Bringing the code with which you can repeat the bug.
• Link to the page where the bug is played.

If you want to write about the problem to the developers club, you should not use the search, read the answer to the FAQ and try in some other way to find a solution to your problem. Think - if everyone will find the answers to the questions themselves, what then will the technical support workers do?

Conclusion

That's all the bad advice we wanted to talk about. In general, typical mistakes for you are tasks for us. If developers step on the same rake while using the API, then this is to some extent our fault. Perhaps we did not provide a case, wrote few examples, poorly done documentation, etc., etc. In particular, in version 2.1 we tried to make it more difficult for a person to make a mistake than in version 2.0. And work in this direction is even higher than the roof.

Do not take our article to heart, improve your projects, send us good and angry wishes. We will explain and tell you everything, even if everything is broken and nothing works =)