В статье я небольшой пример рассматриваю, а в рабочем проекте мы используем платные иконки, а их очень много. Только на скачивание иконок уходило 1.5 mb. Так что это был единственный выход. Или нужно было рефакторить все иконки на проекте
В доке много описано, и связям между слоями уделено отдельное внимание Возможно в некоторых случаях это overhead style. Но идеи заложенные в этой методологии верные, вопрос только как их реализовать.
В русском очень высокая вариативность слов. Падежи, склонения. Если взять все формы самых популярных слов английского языка то выйдет примерно 20т слов, а в русском языке примерно 150 — 200т. Поэтому и обучать GPT на русских текстах намного сложнее
Хорошая статья. DI во фронтенд приложениях нужен еще как.
Где то год назад писал свою реализацию для TS s-di-injector только тут DI строиться через файл конфиг примерно как в Symphony.
Когда мне нужно было оптимизировать сайт. Больше всего времени ушло на профилирование под нагрузкой. Очень выручила эта либа clinicjs.org/doctor Может кому понадобится.
Да это верно. Есть специальные инструменты упрощающие и ускоряющие тестирование. Если не про TDD то можно подобрать подходящие виды тестов. Для фронта, например, юнит тестирование не так важно как интеграционное или E2E.
Rx не про манипуляцию данными на месте.
Все мощь Rx проявляется в ситуациях когда данные к нам приходят в разные моменты времени, и мы можем описать то как они должны взаимодействовать.
Для фильтрации в приведенном коде нам больше всего понадобится функция map. А внутри уже Ramda тогда. Там тоже есть и pipe и compose
TabNine больше отвлекает чем помогает, 2 дня с ним только выдержал. https://www.codium.ai/ намного лучше
Хорошо написано, спасибо.
Нужно в статье только написать источник инфы, https://jamie-wong.com/2016/07/15/ray-marching-signed-distance-functions/
Вариант с Go'шной обработкой ошибок, заставляет нас проверить на ошибки результат. Но с той же легкостью мы можем этого и не делать)
Ленивые разработчики будут писать что-то типа
[chats] = await httpGET('https://api.example.com/chats');
Но на CodeReview такие косяки будет заметнее, и это хорошо.
А вот что плохо, так это загрязнение кода от этих постоянных проверок.
Есть ФП подход к обработке ошибок, он сложнее, но если привыкнуть то гуд.
https://habr.com/ru/post/457098/
В таком случае нужно будет:
переделать получение иконок через прямые импорты (пока обратная совместимость);
выделять время на разбиение частей проекта на чанки;
описать состояния для этапов их загрузки.
Тоже вариант, но труднозатратнее.
В статье я небольшой пример рассматриваю, а в рабочем проекте мы используем платные иконки, а их очень много. Только на скачивание иконок уходило 1.5 mb. Так что это был единственный выход. Или нужно было рефакторить все иконки на проекте
по FCD есть отличное комьюнити, можно им позадавать вопросы https://t.me/feature_sliced
В доке много описано, и связям между слоями уделено отдельное внимание
Возможно в некоторых случаях это overhead style. Но идеи заложенные в этой методологии верные, вопрос только как их реализовать.
Опечатка, поправил. Спасибо что заметили.
Где то год назад писал свою реализацию для TS s-di-injector только тут DI строиться через файл конфиг примерно как в Symphony.
Все мощь Rx проявляется в ситуациях когда данные к нам приходят в разные моменты времени, и мы можем описать то как они должны взаимодействовать.
Для фильтрации в приведенном коде нам больше всего понадобится функция map. А внутри уже Ramda тогда. Там тоже есть и pipe и compose
Вообще, мне нравится эта идея. Можно перевести правила на новый язык запросов. Но этот язык запросов нужно будет изучать отдельно.
На мой взгляд, функции проще и привычнее.