Кейс, когда в качестве childrenв компонент прокидывается примитивный тип, как мне кажется, довольно редкий, чаще всё-таки рендерится какой-то кастомный компонент, куда itemпередаётся через props в том или ином виде – поэтому стоит помнить, что тогда мемоизация не будет работать.
Someone: «Cybernatically» sounds 100% like 80s RoboCop corn
Rich Harris: Exactly our goal! JavaScript tools are boooooring. We shouldn't take ourselves so seriously.
Насчёт разницы между фреймворками — смотря с какой стороны посмотреть, например, Svelte — компилятор, а React/Vue — предоставляют рантайм, который занимается перерисовкой, в этом плане, отличие довольно принципиальное
опять же, вы сравниваете введение в проект на новой технологии, которую вы ещё и сами не знаете, нового разработчика, который тоже её не знает — чего вы ожидаете? библиотека относительно новая, оформленных в виде статей и документации практик и подходов ещё нет достаточно.
плюсами я считаю значительное сокращение размера бандла и лаконичность кода, простейший компонент на Svelte — 1 строка кода.
мы реализовали в данный момент небольшой виджет, и размер кодовой базы по сравнению с React там значительно меньше.
Реализации данных интерфейсов по сути и представляют application services. Единообразный интерфейс необходим, чтобы единообразно применять cross-cutting concerns.
Меня в GraphQL пугают две вещи: производительность и безопасность.
Мне кажется, такие опасения возникают из-за восприятия GraphQL API как интерфейса к БД, хотя по факту GraphQL не привязан к источнику хранения данных.
Представьте, что у вас есть REST-endpoint, который позволяет получить список каких-либо сущностей. В GraphQL вы можете использовать тот же самый код, который получает эти данные для REST. Только GraphQL позволяет отдавать пользователю только те поля, которые он запросил, таким образом, экономя трафик пользователя и уменьшая количество запросов, которые он должен сделать, чтобы получить необходимые данные.
Например, данные вы можете получить с помощью локального HTTP-запроса к микросервису. Несколько запросов к микросервисам внутри локальной сети вашей компании для формирования GraphQL-ответа отработают намного быстрее, чем несколько запросов от пользователя к REST API.
Например, есть какое-то поле, которое очень затратно выбирать и по хорошему нужно использовать разные запросы на БД
Создайте отдельный resolver для этого поля и укажите, каким образом это поле должно извлекаться из хранилища.
Или нужно разграничить набор возвращаемых данных в зависимости от роли пользователя
А каким образом вы бы реализовали это в REST API? В GraphQL, например, разграничить доступ к полям можно с помощью директив, указанных на каждом поле, где необходима проверка доступа. Вот статья, описывающая такой подход: codeburst.io/use-custom-directives-to-protect-your-graphql-apis-a78cbbe17355, но это не единственный возможный вариант решения.
А вы используете директивы в своем проекте? Что-то в graphql-dotnet намудрили с ними, и свои директивы непонятно как реализовывать. В apolloserver директивы очень просто добавляются
Поделитесь опытом о расположении в проекте объектов, связанных с DI-контейнером (например, профили Autofac), объектов, связанных с Automapper (профили), различных инфраструктурных вещей (ActionFilters, ModelBinders, Helpers, etc). Интересует структура и иерархия директорий.
Рекомендую обновить readme на гитхабе. Сейчас там нет никакой информации об использовании. Я понимаю, что есть тесты, но первое впечатление о проекте складывается именно по readme-файлу, как мне кажется
статья выглядит как заглушка с неважно каким контентом для рекламы компании в конце
достаточно тапнуть и держать палец на экране, чтобы текущая сторис "застыла" и не сменялась на следующую :)
Пример, где используется
React.memo, довольно обманчивыйМемоизация работает:
Мемоизация НЕ работает:
Кейс, когда в качестве
childrenв компонент прокидывается примитивный тип, как мне кажется, довольно редкий, чаще всё-таки рендерится какой-то кастомный компонент, кудаitemпередаётся черезpropsв том или ином виде – поэтому стоит помнить, что тогда мемоизация не будет работать.в одной из статей он рассказывает, почему именно Svelte, а не условный React (ответ: на телевизорах и кассах React тормозит, Svelte – нет)
я имею в виду, что библиотеки и становятся популярными, когда кто-то первый их использует и рассказывает другим
Насчёт разницы между фреймворками — смотря с какой стороны посмотреть, например, Svelte — компилятор, а React/Vue — предоставляют рантайм, который занимается перерисовкой, в этом плане, отличие довольно принципиальное
плюсами я считаю значительное сокращение размера бандла и лаконичность кода, простейший компонент на Svelte — 1 строка кода.
мы реализовали в данный момент небольшой виджет, и размер кодовой базы по сравнению с React там значительно меньше.
Интерфейсы, описанные в статье, не имеют отношения к слою доступа данных. Это более высокий слой приложения
Представьте, что у вас есть REST-endpoint, который позволяет получить список каких-либо сущностей. В GraphQL вы можете использовать тот же самый код, который получает эти данные для REST. Только GraphQL позволяет отдавать пользователю только те поля, которые он запросил, таким образом, экономя трафик пользователя и уменьшая количество запросов, которые он должен сделать, чтобы получить необходимые данные.
Например, данные вы можете получить с помощью локального HTTP-запроса к микросервису. Несколько запросов к микросервисам внутри локальной сети вашей компании для формирования GraphQL-ответа отработают намного быстрее, чем несколько запросов от пользователя к REST API.
Создайте отдельный resolver для этого поля и укажите, каким образом это поле должно извлекаться из хранилища.
А каким образом вы бы реализовали это в REST API? В GraphQL, например, разграничить доступ к полям можно с помощью директив, указанных на каждом поле, где необходима проверка доступа. Вот статья, описывающая такой подход: codeburst.io/use-custom-directives-to-protect-your-graphql-apis-a78cbbe17355, но это не единственный возможный вариант решения.