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

    If there are
    too many people chasing you ,
    Ask them in detail.
    What are they upset with?
    Try to console everyone.
    Give everyone advice,
    But to reduce the speed at the same time
    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.Maps API ceases to be a beta version and becomes the main one .

    For this event, we completely updated the documentation, 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 about it enough during the beta launch. Let's talk about using the Yandex.Maps API in general.

    API development is a very specific programming area. The needs and skills of API users are superimposed on any idea of ​​a designer and developer. The main feedback we receive is user messagesin 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 wiggle on a mustache.

    Some things often do wrong. Today I want to talk about them. All the tips you read are harmful. If you realize that you are following some of the recommendations of this article, it's okay - it's never too late to make your project a little better. So, Irony mode ON.

    In no case 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? "To go from my silicone valley to Gus Khrustalny to forbid me to use my pirate Windows?"
    If you use the Yandex.Maps API, you should adhere to the same strategy.

    Because if you read the user agreement , you can understand that it’s illegal to implement your cool idea on the API. For example, you will not be able to do vehicle monitoring or use the API in the admin panel to 1C. Or something worse.

    Therefore, just before starting work, give yourself a setting - if you have not read the agreement, you are basically not aware of the limitations and the world of cartography is unlimited for you. Of course, there’s 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 solved as they become available, so we are quietly moving on.

    In general, the ideal option is to create a website, give it to the customer, get an honestly earned salary 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 kind of documentation.

    As you know, good code needs no comments. Similarly, a good API does not need documentation. In general, any library or module should be intuitive, and an ideal API should not require programming skills. Therefore, if you want to look at examples in our sandbox, or read something about the API features in the manual, or even more so look into the directory (!), Fight with an impulse. The right strategy - to randomly select one example (preferably the least detailed) and listen to the call of the heart - it will tell you how to write.

    So, where you should not look before starting application development:

    Don’t think about JavaScript.

    As you know, a JavaScript programmer is not a programmer, but he is a typesetter. You should never be confused with the thought that the API you want to use is written in JavaScript. Studying the construction of this language (if you can say so at all), you risk forgetting something important from another language, get confused and everything will go to waste.

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

    myPlacemark = new ymaps.Placemark(["" ,"" ]);

    See how gracefully we dispensed with JavaScript!

    This approach allows you to avoid many unpleasant consequences.
    • Your application will run slowly enough to give the user time to think about the meaning of life.
    • Your code will not require obfuscation, as it is quite confusing from the very beginning.
    • The page code will not be cached by the browser, but will be generated each time again on the server.

    It is sad that many programmers still try to go against the system. They write code in pure, well-structured JavaScript. They load data in batches at the same URL, clogging the browser cache. As a result, their applications are fast, users take it for granted and do not even look at other sites. Think about the younger generation - stop making websites where schoolchildren spend their youth, free humanity from Internet addiction!

    A book not worth reading if you decide to develop a JavaScript application:


    Avoid structuring code

    If you plan to do something a little more complicated than the location map, it may come to your mind to consider the architecture of your site. You might even want to highlight components in the code, create classes, or break the code into functions.

    This should not be done for several reasons:
    • Modularized code is difficult to read because the commands are out of order.
    • The development of architecture requires a lot of time.
    • An application using cards is simply not worthy of your time and attention. Point.

    Things to Avoid When Developing an Application Using Maps:
    • No need to break the code into classes or functions.
    • You should not use modular systems, you do not need any RequireJS.
    • No need to separate the code and data into different files - if there are a lot of files, it’s easy to get confused.

    Unfortunately, we have examples that, contrary to all, use these approaches. You can see and evaluate their absurdity in the sandbox .

    // Задание собственного модуля.
    ymaps.modules.define('CustomModule', function (provide) {
        var CustomModule = function (defValue) {
            this.field = defValue;
    // Запрос модулей.
            function (CustomModule) {
                // ...

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

    Books that may prevent you from writing perfect code have been written by insidious people. Their value system is turned upside down. The enemy must be known in person, here are some of the potentially dangerous publications:


    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 right way is to download the data immediately and preferably before loading the contents of the page on which the map is shown. Think for yourself - if not now, then when? A person can turn off the Internet and then our tags cried. Not all programmers have understood this simple truth and are still trying to download data on demand.

    Here's a sad example showing how to load data into a tag balloon on demand. Here is another sad example showing how to create a map on demand. And what only these developers do not fall for ...

    Download with stock

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

    Here it will not be amiss to recall the cases when you sent a friend for a can of cola, and he brought one. Exactly the same rule works for loading code. It’s better to download the entire API code — you never know what comes in handy. In version 2.0, developers created packages that the user can accidentally start using if they copy an example from the sandbox without hesitation.


    How to avoid such errors? When using version 2.0, any combinations of loadable modules must be changed to package.full. With this approach, the user will get much more code, which is good.

    In version 2.1, developers, unfortunately, detected that people did not give in to provocations and loaded the whole API. Therefore, in version 2.1, packages were canceled altogether, and package.full is now divided into parts that are loaded asynchronously as needed.
    Instead of packages, you can now connect single modules that you want to use. Generally without any reserve.


    Programming well is getting harder.

    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, demonstrating the operation of all available controls, and add the code to your site as is.

    An experienced user may notice that not all controls are presented on this map. Careless programmers forgot to add a second zoom 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: both large and small controls. Why it took to make an example worse remains a mystery to this day.

    Version 2.1 again put us on the bandwagon. It has fewer controls (villains sawed out a mini-map), they are installed on the map by default and collapse to a small size on a small map.

    See for yourself - there are few buttons, they themselves are small. The map is generally 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 courageously apply them to the card 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 everyone else), the browser grunts and freezes indefinitely. It serves him right.

    Developers trying to hide the imperfections of browsers mask their flaws in very sophisticated ways:
    • Use clustering of objects. We have devoted a lot of examples to this ingenious trick, and even an entire article .
    • Use technology of active areas. Despite the complexity of the development, it removes any restrictions on the number of displayed objects. You can evaluate the insidiousness of the concept by reading the developer 's guide or by looking at an example in the sandbox.

    Do not try to save geocoder requests

    Very often, users are faced with this problem. They have a list of addresses for shops, pharmacies, attractions, and more. All these addresses must 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 into the coordinates of the labels on the client.

    An unprepared reader may ask, “Is it correct that the set of labels is the same and that it is geocoded each time each application of my application is called up by each user again?” We answer this question directly: "Do not worry." Yandex servers are quite fault tolerant and can 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 litter 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 topic in the developer's guide.


    And it was not laziness ...

    Do not take bread from technical support

    At some point, you may feel a strange irresistible desire to chat with the Yandex.Maps API technical support service. This event needs to be taken seriously, and not anyhow.

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

    Here is a good example of contacting a club:

    A developer at the sight of this message instantly realizes that all his work is perishable. The universe emerged from a big bang, is expanding and is about to collapse. Everything is lost. Nothing works.

    Things to avoid when contacting tech support or a club:
    • Detailed description of the problem.
    • Bringing 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 development 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 answers to the questions themselves, then what will technical support workers do?


    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 using the API, then this is to some extent our fault. Perhaps we did not provide a case, wrote few examples, poorly made 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 =)

    Also popular now: