• JavaScript 2016, а можно попроще?
    0

    да, точно, исправил, я сам пользуюсь lodash, ramda для примера привел :)

  • JavaScript 2016, а можно попроще?
    0

    или воспользоваться существующими, вот пример форка где есть больше возможностей для кастомной конфигурации


    https://www.npmjs.com/package/custom-react-scripts

  • JavaScript 2016, а можно попроще?
    +3

    В отличии от готового boilerplate шаблона для клиентской сборки, create-react-app это отдельный пакет. Это значит что его легко интегрировать, легко обновить в будущем. Представте что у вас уже есть проект с кучей зависимостей, если вы хотите прикрутить к нему какой-то шаблон, то вам нужно вручную его смержить. К тому же create-react-app гораздо качественее большинства других шаблонов.

  • JavaScript 2016, а можно попроще?
    +1

    К сожалению, на JQuery особо проще не будет, SPA писать сложнее, чем приложение на пост-бэках. Показывать модальные окна, валидировать ввод пользователя, генерировать HTML по из шаблонов, с JQuery тоже не тривиальная задача. Но в отличии от React или подобных фреймворков, JQuery решение хуже маштабируется, когда проект становится больше. Проще не значит просто :)

  • Строим свой full-stack на JavaScript: Клиент
    0

    Общепринятая практика при разработке API при ошибке вернуть подходящий ошибочный HTTP код (не 200) и какие-то данные об ошибке. На своих проектах я предпочитаю при любой ошибке возвращать стандартный ошибочный код 500 (Server Error) и передавать строковый код ошибки (например no_rights_to_edit), тогда на клиенте можно проверить код ошибки и в зависимости от него показывать нужное сообщение. Если при этом API используются только для одного клиента, то можно сразу с сервера передавать сообщение, которое можно показать на клиенте.


    Ошибки AJAX запросов можно и нужно обрабатывать. Я имел в виду, что не обрабатываются другие ошибки, например обращение к underfined переменной или прочие непредвиденные ситуации.

  • Строим свой full-stack на JavaScript: Сервер
    0

    Спасибо, исправил!


    Я не показываю подробно всего, что можно сделать в кастомной ошибке, это зависит от конкретного проекта, например в своих проектах я обычно добавляю свойство uiShow, которое определяет показывать ли ошибку на клиенте как есть или общее сообщение типа "Server Error", а текст ошибки вычитывается по коду ошибки, а не преобразует сам код в виде читабельной строки.

  • Строим свой full-stack на JavaScript: Сервер
    0

    Да, спасибо, нужно добавить.

  • Строим свой full-stack на JavaScript: Сервер
    0

    Я не утверждаю, что TypeScript это тоже самое, что JS, но большинство того, что описываю в этой сатье не зависимо от того что конкретно используется.


    TS расширение JS, поэтому код на TS должно быть легко читать даже тем, кто с TS не знаком.


    Например flow от Facebook, вообще позиционируется как static type checker, а не отдельный язык, хоть и добавляет аннотации типов в JS.


    Как я уже писал TS имеет как плюсы так и минусы и каждый сам решает насколько ему это подходит, я планирую добавить альтернативную ветку в Contoso с JS имплементацией.

  • Строим свой full-stack на JavaScript: Основы
    0
    Это уже перегиб, для подобных задач я использую lodash, а если пакет это всего одна функция, то лучше добавить скопипастить эту функцию как утилитный метод проекта. Я имел в виду небольшие пакеты в плане: пакет логирования, пакет отправки имейлов, т.д.
  • Go глазами java программиста
    –4
    Спасибо, интересная статья!
  • StubDb — база данных на стабах для быстрого прототипирования и не только
    0
    Спасибо!

    Да я видел либо этот либо похожий. Но я хотел чтобы во-первых это работало и без EF, а главное чтобы можно было хранить данные об объектах с учетом взаимосвязи между ними.

    Т.е., например, если есть пост и комментарии к нему, можно было добавить пост с комментариями в коллекцию постов, а потом при запросе к коллекции комментариев в каждом комментарии был выставлен соответствующий пост.

    Таких решений я не находил.
  • StubDb — база данных на стабах для быстрого прототипирования и не только
    +1
    На самом деле, я написал StubDb из-за того, что друг учит программирование и для того, чтобы ему изучить ASP.NET MVC ему еще нужно выучить SQL и Entity Framework. Я сделал StubDb предельно простой в использовании и похожей на EF CF. Объяснить ему StubDB было просто и он успешно использовал ее в обучении. MyUniversity в примерах использования был сделан им на стабах.

    Я не утверждаю, что не нужно учить БД, просто нет необходимости учить все сразу. Скорее всего, если ты .NET developer, то придется работать с EF и SQL Server, но есть еще NHibernate, есть MongoDb и другие SQL БД.

    То, что «одна из первейших областей программирования после синтаксиса — БД» — не верно. Например, в ASP.NET MVC приложении, после синтаксиса C#, есть еще сами особенности MVC, архитектура с разбиением на доменную логику и модели, Dependency Injection и т.д, ну а уже потом БД.

    В любом случае, обучение программированию не основная область применения этой библиотеки :)