В отличии от готового boilerplate шаблона для клиентской сборки, create-react-app это отдельный пакет. Это значит что его легко интегрировать, легко обновить в будущем. Представте что у вас уже есть проект с кучей зависимостей, если вы хотите прикрутить к нему какой-то шаблон, то вам нужно вручную его смержить. К тому же create-react-app гораздо качественее большинства других шаблонов.
К сожалению, на JQuery особо проще не будет, SPA писать сложнее, чем приложение на пост-бэках. Показывать модальные окна, валидировать ввод пользователя, генерировать HTML по из шаблонов, с JQuery тоже не тривиальная задача. Но в отличии от React или подобных фреймворков, JQuery решение хуже маштабируется, когда проект становится больше. Проще не значит просто :)
Общепринятая практика при разработке API при ошибке вернуть подходящий ошибочный HTTP код (не 200) и какие-то данные об ошибке. На своих проектах я предпочитаю при любой ошибке возвращать стандартный ошибочный код 500 (Server Error) и передавать строковый код ошибки (например no_rights_to_edit), тогда на клиенте можно проверить код ошибки и в зависимости от него показывать нужное сообщение. Если при этом API используются только для одного клиента, то можно сразу с сервера передавать сообщение, которое можно показать на клиенте.
Ошибки AJAX запросов можно и нужно обрабатывать. Я имел в виду, что не обрабатываются другие ошибки, например обращение к underfined переменной или прочие непредвиденные ситуации.
Я не показываю подробно всего, что можно сделать в кастомной ошибке, это зависит от конкретного проекта, например в своих проектах я обычно добавляю свойство uiShow, которое определяет показывать ли ошибку на клиенте как есть или общее сообщение типа "Server Error", а текст ошибки вычитывается по коду ошибки, а не преобразует сам код в виде читабельной строки.
Я не утверждаю, что TypeScript это тоже самое, что JS, но большинство того, что описываю в этой сатье не зависимо от того что конкретно используется.
TS расширение JS, поэтому код на TS должно быть легко читать даже тем, кто с TS не знаком.
Например flow от Facebook, вообще позиционируется как static type checker, а не отдельный язык, хоть и добавляет аннотации типов в JS.
Как я уже писал TS имеет как плюсы так и минусы и каждый сам решает насколько ему это подходит, я планирую добавить альтернативную ветку в Contoso с JS имплементацией.
Это уже перегиб, для подобных задач я использую lodash, а если пакет это всего одна функция, то лучше добавить скопипастить эту функцию как утилитный метод проекта. Я имел в виду небольшие пакеты в плане: пакет логирования, пакет отправки имейлов, т.д.
Да я видел либо этот либо похожий. Но я хотел чтобы во-первых это работало и без EF, а главное чтобы можно было хранить данные об объектах с учетом взаимосвязи между ними.
Т.е., например, если есть пост и комментарии к нему, можно было добавить пост с комментариями в коллекцию постов, а потом при запросе к коллекции комментариев в каждом комментарии был выставлен соответствующий пост.
На самом деле, я написал 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 и т.д, ну а уже потом БД.
В любом случае, обучение программированию не основная область применения этой библиотеки :)
да, точно, исправил, я сам пользуюсь lodash, ramda для примера привел :)
или воспользоваться существующими, вот пример форка где есть больше возможностей для кастомной конфигурации
https://www.npmjs.com/package/custom-react-scripts
В отличии от готового boilerplate шаблона для клиентской сборки, create-react-app это отдельный пакет. Это значит что его легко интегрировать, легко обновить в будущем. Представте что у вас уже есть проект с кучей зависимостей, если вы хотите прикрутить к нему какой-то шаблон, то вам нужно вручную его смержить. К тому же create-react-app гораздо качественее большинства других шаблонов.
К сожалению, на JQuery особо проще не будет, SPA писать сложнее, чем приложение на пост-бэках. Показывать модальные окна, валидировать ввод пользователя, генерировать HTML по из шаблонов, с JQuery тоже не тривиальная задача. Но в отличии от React или подобных фреймворков, JQuery решение хуже маштабируется, когда проект становится больше. Проще не значит просто :)
Общепринятая практика при разработке API при ошибке вернуть подходящий ошибочный HTTP код (не 200) и какие-то данные об ошибке. На своих проектах я предпочитаю при любой ошибке возвращать стандартный ошибочный код 500 (Server Error) и передавать строковый код ошибки (например no_rights_to_edit), тогда на клиенте можно проверить код ошибки и в зависимости от него показывать нужное сообщение. Если при этом API используются только для одного клиента, то можно сразу с сервера передавать сообщение, которое можно показать на клиенте.
Ошибки AJAX запросов можно и нужно обрабатывать. Я имел в виду, что не обрабатываются другие ошибки, например обращение к underfined переменной или прочие непредвиденные ситуации.
Спасибо, исправил!
Я не показываю подробно всего, что можно сделать в кастомной ошибке, это зависит от конкретного проекта, например в своих проектах я обычно добавляю свойство uiShow, которое определяет показывать ли ошибку на клиенте как есть или общее сообщение типа "Server Error", а текст ошибки вычитывается по коду ошибки, а не преобразует сам код в виде читабельной строки.
Да, спасибо, нужно добавить.
Я не утверждаю, что TypeScript это тоже самое, что JS, но большинство того, что описываю в этой сатье не зависимо от того что конкретно используется.
TS расширение JS, поэтому код на TS должно быть легко читать даже тем, кто с TS не знаком.
Например flow от Facebook, вообще позиционируется как static type checker, а не отдельный язык, хоть и добавляет аннотации типов в JS.
Как я уже писал TS имеет как плюсы так и минусы и каждый сам решает насколько ему это подходит, я планирую добавить альтернативную ветку в Contoso с JS имплементацией.
Да я видел либо этот либо похожий. Но я хотел чтобы во-первых это работало и без EF, а главное чтобы можно было хранить данные об объектах с учетом взаимосвязи между ними.
Т.е., например, если есть пост и комментарии к нему, можно было добавить пост с комментариями в коллекцию постов, а потом при запросе к коллекции комментариев в каждом комментарии был выставлен соответствующий пост.
Таких решений я не находил.
Я не утверждаю, что не нужно учить БД, просто нет необходимости учить все сразу. Скорее всего, если ты .NET developer, то придется работать с EF и SQL Server, но есть еще NHibernate, есть MongoDb и другие SQL БД.
То, что «одна из первейших областей программирования после синтаксиса — БД» — не верно. Например, в ASP.NET MVC приложении, после синтаксиса C#, есть еще сами особенности MVC, архитектура с разбиением на доменную логику и модели, Dependency Injection и т.д, ну а уже потом БД.
В любом случае, обучение программированию не основная область применения этой библиотеки :)