Ответы пользователя по тегу JavaScript
  • Какие недочеты вы скажете по коду?

    @xfg
    Высокая цикломатическая сложность подобного кода. Бизнес-логика смешивается с DOM. Практически весь код дублируется.

    Такой код сложно поддерживать. Сложно читать. Сложно тестировать. Это действительно слабо. Всё же мы пишем для людей, а не для компьютера. Написать сложный код, очень просто. Написать простой код, очень сложно.
    Ответ написан
  • Как мне тестировать подобный код, нужно ли его тестировать вообще, если да - то как?

    @xfg
    Тестировать нужно. Необходимо проверить, что запрос из вашего приложения действительно уходит во вне и что из вне возвращается то, что ожидается. Поскольку обращаться к реальному registry внутри тестов это неверно, то необходимо поднять локальный registry и настроить npm-cli на работу с локальным registry вместо npm-registry для целей тестирования. Взять registry можно здесь, бросить .npmrc в директорию из под которой запускаются тесты с указанием вашего локального registry и теперь npm-cli из тестов будет ходить на локальный registry вместо реального.

    Это интеграционный тест, не юнит. Здесь задача протестировать границу между двумя модулями. Убедиться, что связка действительно работает.

    В целом, это тоже самое, когда вы тестируете работу вашего приложения с базой данных и для этих целей создаете фейковую базу, с фейковыми данными.
    Ответ написан
  • Какой JS фреймворк выбрать для full-stack?

    @xfg
    Лучшее что сейчас есть это koa или express для http протокола и socket.io для websocket протокола. PHP тоже от full-stack фреймворков движется в сторону микрофреймворков. Сегодня современный фреймворк это роутинг запросов реализованный на концепции мидлваров.

    Проблема спагетти-кода решается не фреймворком, а архитектурой. На сервере это обычно multilayered architecture. Бьете приложение на 4 слоя presentation, application, domain и infrastructure (еще могут называть data access layer или persistence layer). Контроллеры фреймворка куда попадает запрос пользователя это будет ваш самый верхний presentation слой. Слой инфраструктуры лучше собирать из отдельных библиотек, чем завязывать его на фреймворк. В таком случае не придется переписывать весь слой инфраструктуры из-за того, что фреймворк больше не развивается. Application и Domain слои используют Infrastructure слой через интерфейсы, тем самым абстрагируясь от конкретных реализаций. Таким образом вы всегда сможете заменить одну реализацию другой (паттерн Strategy) без изменения вышестоящих слоев. Presentation слой просто вызывает сервисы из application слоя и возвращает результат в html/json/xml/etc клиенту.

    Иногда упрощают до 3 или даже 2 слоев. Например если у вас CRUD приложение, тогда application и domain слои не нужны и вы можете оставить только presentation и infrastructure. Также если ваш application слой не делает ничего, кроме вызова domain слоя, то от него также можно избавиться оставив 3 слоя presentation, domain и infrastructure.

    Примеры реализации можно найти здесь и здесь. Они на Java. На javascript пока не встречал.

    Более подробно тему можно изучить взяв любую книгу на эту тему.

    Meteor не советую. Это не будущее. Это костыль. Они хотели сделать фреймворк для real-time приложений. Но фактически получилась просто платформа для стриминга произошедших изменений в mongo прямо на клиент.

    Sails это попытка сделать full-stack фреймворк. Но весь мир движется в обратном направлении.
    Ответ написан
  • Правильное тестирование Javascript?

    @xfg
    В случае если объект внутри себя инстанциирует другой объект, тогда такой объект должен рассматриваться как единый юнит.

    import LineItem from './LineItem';
    
    class Order {
      constructor(lineItems = []) {
        this.lineItems = lineItems;
      }
      addLineItem(name, cost, quantity) {
        this.lineItems.push(new LineItem(name, cost, quantity));
      }
    }


    В этом случае писать юнит-тест необходимо на класс Order. Необходимости в тестировании класса LineItem нет, так как он является составной частью класса Order. Такие классы носят название - Агрегат. Когда автосалон вас приглашает на тест-драйв автомобиля, то это предполагает тестирование Агрегата в целом, то есть Автомобиля. Тестировать отдельно составные его части такие как колеса/двигатель мы не будем.

    В случае если объект принимает другой объект из вне, тогда такие объекты должны рассматриваться как отдельные юниты.

    class Route {...}
    class Ship {
      addRoute(route) {
       if (!(route instanceof Route)) {
         throw new Error('route must be instance of Route');
       }
        this.route = route;
      }
      ...
    }


    В этом случае необходимо писать отдельные юнит-тесты на Route и на Ship. Чтобы написать юнит-тест на класс Ship его необходимо изолировать от класса Route с помощью мок-объекта.

    Интеграционный тест подразумевает, что вы не будете подменять Route на мок-объект, чтобы протестировать класс Ship. Вместо это необходимо передать настоящую реализацию класса Route. В таком случае мы протестируем взаимодействие между двумя юнитами Ship и Route.
    Ответ написан
  • Нужен совет от фул стек фрилансеров. Стоит ли пытаться стать профи и в js и в php?

    @xfg
    Можно. Посмотрите, что такое event loop и как работает. И считайте, что вы знаете javascript. Все остальное не особо отличается от других языков и раз всю жизнь были программистом, то скорее всего уже встречались с async/await, декораторами, замыканиями, импортами и всем остальным. Если нет, не проблема будет ознакомиться. Все копируют всё друг у друга.
    Ответ написан
  • Как повысить уровень программирования?

    @xfg
    Если говорим об ООП подходе, то прочитать книгу по DDD от Вон Вернона. Фактически автор описывает, как строить многоуровневую архитектуру, чтобы разделить кашу из бизнес-логики, работы с хранилищем, приложением и представлением, на отдельные слои с однонаправленным потоком данных. Книга задает вектор движения и позволяет минимизировать собственные творческие шатания из стороны в сторону, которые приводят в итоге к спагетти коду.
    Ответ написан
  • ORM в nodeJS, как это должно работать?

    @xfg
    Не совсем понятно, что хотите получить. Но можете посмотреть typeorm. Это единственная orm в node.js реализующая паттерн data mapper, все остальные реализуют паттерн active record. Но условия выборки всё равно придется писать.
    Ответ написан
  • Как выполнять последовательно действия через определенный промежуток времени?

    @xfg
    Поискать таск менеджер с возможностью отложенной обработки задач. Например kue умеет отложенные задачи ставить в очередь https://github.com/Automattic/kue#delayed-jobs и затем написать обработчик этих задач, который будет что-то делать, например отправлять данные пользователю через сокет. Можно поискать альтернативы kue работающие напрямую с памятью, если не хотите раздувать стек технологий редисом. Но более-менее популярных альтернатив я не встречал.
    Ответ написан
  • Какой выбрать набор инструментов и порядок их изучения для веба?

    @xfg
    Изучай синтаксис JS если хочешь, но читай умные книжки по архитектуре. Культура кода в JS крайне низкая сейчас. А Node.js это просто платформа для выполнения javascript кода на сервере. Учить там нечего, открыл api, да сделал. Но сначала конечно нужно изучить синтаксис любого языка, который поддерживает ту парадигму, которая тебе интересна, иначе книги по архитектуре будут совсем непонятны. Сейчас доминирует ООП. Поэтому можешь брать любой который нравится JS, Python, PHP, Ruby. Без разницы, все они умеют ооп, в JS используют prototype-based, но это просто один из стилей объектно-ориентированного программирования, суть не меняется. Ну и в JS ооп немного коцаное, но есть языки компилирующиеся в JS призванные исправить это недоразумение, типа TypeScript.
    Ответ написан
  • Не убьёт ли WebAssembly node.js?

    @xfg
    WebAssembly это низкоуровневый язык программирования. Никто на нем в здравом уме не будет писать. Это почти тоже самое, как пытаться писать веб с помощью ассемблера. В него просто будут компилировать код с других языков, сейчас пока только C и C++, позже будут и другие. Он нужен, чтобы ускорить клиент-сайд, поскольку javascript медленный для всяких там 3D игр и всего такого. В общем походу скоро php захватит и клиент :)

    Кроме того, эта идея уже была ранее реализована в asm.js от компании Mozilla. Разработчики сделали на C++ демку 3d игры скомилировали её в asm.js, общественность немного поигралась и всё заглохло. Революции не произошло.
    Ответ написан
  • Модульность на фронтенде?

    @xfg
    Посмотрите yeoman.io у него огромное количество генераторов это заготовки для старта проекта, можно найти заготовку под что угодно. Структура проекта, препроцессоры, сжатия, оптимизации, юнит-тесты, всё уже настроено. Нужно взять и использовать. Делать всё с нуля, особенно первые разы не стоит. Стоит сначала посмотреть, как это принято правильно делать.
    Ответ написан
  • Как правильно клонировать объект на JS?

    @xfg
    Ну у вас просто не глубокое копирование. А реализация от ангуляра делает глубокое копирование (deep copy). Вот и всё. А вообще юзайте lodash там уже всё есть.
    Ответ написан
  • Какую версию nodejs изучать?

    @xfg
    Ну 6, хотя по факту, там от версии к версии немного меняется api, что-то помечают депрекейтед, что-то удаляют/добавляют, обновляют версию движка V8 и всё такое. Глобальных изменений, когда меняется всё и вся, такого нет.

    Вобще это всего лишь платформа для выполнения javascript кода, расширенная собственным api для работы с файлами, потоками и т.д. Если требуется использовать что-то из api nodejs то открыл доку и почитал, какие там есть свойства/методы и что вообще делает модуль. Всё. Это же не язык программирования, скажи что там можно изучать?
    Ответ написан
  • С помощью чего писать тесты для сайта?

    @xfg
    Из популярных для юнит-тестов
    mocha
    jasmine
    Для end-to-end тестов
    nightwatch
    protractor

    Да, можно тестировать как клиентскую часть, так и серверную. На клиентской части когда пишешь юнит-тесты может возникнуть проблема с DOM, так как не очень понятно, как мокать такие зависимости. Поэтому клиент сайд фреймворки, такие как angular пропагандируют подход к написанию кода таким образом, чтобы бизнес-логика никогда не перемешивалась с DOM. Таким образом всю важную бизнес-логику можно будет покрыть юнит-тестами, без всяких проблем.

    Функциональные (end-to-end) тесты эмулируют поведение пользователя через реальный браузер. То есть end-to-end тест нажимает кнопочки, заполняет поля, ходит по ссылкам. Эти тесты более медленные, чем юнит-тесты. Изменения в верстке страницы могут их поломать. Но они более высокоуровневые, дают убедиться, что страница работает именно так как предполагалось. Не зависят от кода, а следовательно не имеют проблем с DOM в отличие от юнит-тестов.

    Лично я пишу только юнит-тесты. И не пишу интеграционные и функциональные. Юнит-тесты очень быстрые, можно в автоматическом режиме прогонять при каждом сохранении файла проекта. В тоже время они дают приемлемый уровень уверенности в том, что билд проекта скорее будет работать, чем нет. Если писать все типы тестов, то можно выстрелить себе в ногу. Будет медленее. Будет больше проблем с исправлением кучи всяких разных тестов.
    Ответ написан
  • Может ли перезагрузка страницы оборвать запись данных в localStorage?

    @xfg
    Если в сторадж последовательно записывается несколько значений, то да, может. Если в сторадж пишется одно значение, то нет, это атомарная операция. Для первого случая вроде есть решения stackoverflow.com/questions/14330477/atomic-operat...
    Ответ написан
  • Почему нет сильной Ecommerce платформы под node.js?

    @xfg
    Потому что на node.js как не пиши, но любое более менее сложное приложение превращается в процедурную лапшу. Абстракций и полиморфизма типов нет, приходится зависеть от конкретных реализаций. В метеоре на котором вы написали свое приложение нет di контейнера, всё валится в глобальную область видимости, используется монго, не поддерживаются транзакции между документами/коллекциями, сильная связанность, тяжело покрыть тестами.

    Впечатление от этого всего, что вернулся в начало 2000-ых. Нужно ждать, пока спецификацию ecmascript допилят до вменяемого состояния. Но я думаю, что к тому времени в том же php уже будет асинхронность из коробки, тем более у разработчиков это в планах.
    Ответ написан
  • Какой выбрать фреймворк для частичного обновления DOM?

    @xfg
    Никакой. JS фреймворки предназначены для создания клиентского приложения. У вас клиента быть не может, т.к. всё рендерится на сервере. Поэтому только низкоуровневые библиотеки аля jquery.
    Ответ написан
  • Что все-таки должен уметь делать frond-end-разработчик?

    @xfg
    Бекендер предоставляет api для манипулирования данными, а ваша задача эти данные отобразить конечному пользователю. Взаимодействие с сервером ваша задача. Вы делаете полностью клиент. На каком фреймворке или без, вам решать. Но в подавляющем большинстве случаев пишут classic websites, где клиентская часть генерится на сервере и клиент соответственно писать не нужно, поэтому весь сайт делает бекендер, отдать можно только верстку верстальщику, а фронтендер в таком проекте не нужен.

    Фронтендер такой же программист. Скажем у фейсбука есть API, вас просят написать веб клиент к этому api. И вы должны это сделать. На выходе должен быть готовый продукт, которым уже может пользоваться конечный потребитель. Это фронтендер. Это его отличает от верстальщика, задача которого картинку напилить в html.
    Ответ написан