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

Посмотри исходники либы.

Посмотри исходники либы.

browser-cookie парсит, форматирует, добавляет удобство, действия get, set, del. Не вижу какой-то необходимости пока тащить либу, если мой велосипед в одно действие на ту же тему будет короче.

хочу отделить стор, вью и логику на три разных слоя чтобы можно было: - тестить логику без view вообще - тестить view отдельно от логики - менять логику без трогания view

интересную штуку делаешь у меня какраз была задача где пришлось на компонент возложить много логики. очень расстраивала она меня. С вьюшками понятно простов компонентах держишь. А как решаешь проблему с контейнерами, и как пробрасываешь логику до вью. И как ее держишь

интересную штуку делаешь у меня какраз была задача где пришлось на компонент возложить много логики. очень расстраивала она меня. С вьюшками понятно простов компонентах держишь. А как решаешь проблему с контейнерами, и как пробрасываешь логику до вью. И как ее держишь

Логика крутится отдельно от стора и вью. Контейнеры это компоненты которые знают как подписываться на стор. Полностью от этого не уйти. Ибо Вью всегда будет зависеть от стора. view = f(data) Вью лишь знает о том какие события кидать в логику. Логика может произвольно подписываться на события. Собственно логику можно менять не трогая вью Прототип: github.com/sergeysova/storied

хочу отделить стор, вью и логику на три разных слоя чтобы можно было: - тестить логику без view вообще - тестить view отдельно от логики - менять логику без трогания view

хочешь к псевдо-мввм прийти ?

Логика крутится отдельно от стора и вью. Контейнеры это компоненты которые знают как подписываться на стор. Полностью от этого не уйти. Ибо Вью всегда будет зависеть от стора. view = f(data) Вью лишь знает о том какие события кидать в логику. Логика может произвольно подписываться на события. Собственно логику можно менять не трогая вью Прототип: github.com/sergeysova/storied

тоесть ты вынес сложные функции в классы. Далее нужные объекты для работы с данными, ты пробрасываешь во вью, и на уровне вьюшки прокидываешь данные в логику, Я все верно понял ?

хочешь к псевдо-мввм прийти ?

Не знаю. Пока что не ложится на эти термины

Привет! Работал ли кто с keycloak? Возможно ли сделать авторизацию в этом сервисе через ajax запросы? Спасибо)

тоесть ты вынес сложные функции в классы. Далее нужные объекты для работы с данными, ты пробрасываешь во вью, и на уровне вьюшки прокидываешь данные в логику, Я все верно понял ?

Не. Классов нет. Стор можно использовать абсолютно любой. События здесь буквальные event Emitter.

Не. Классов нет. Стор можно использовать абсолютно любой. События здесь буквальные event Emitter.

EventEmitter Это вроде нодовский обработчик ?

EventEmitter Это вроде нодовский обработчик ?

Pattern

EventEmitter Это вроде нодовский обработчик ?

Это просто паттерн. Реализуется на любом языке. Просто в ноде он в основе архитектуры

Это просто паттерн. Реализуется на любом языке. Просто в ноде он в основе архитектуры

Может я дурак совсем, но разве это не observer?

Может я дурак совсем, но разве это не observer?

Нет

Это два разных паттерна

есть массив, сначала делаю map, потом filter у кого есть примеры обхода массива один раз через редьюс ?

а чо сложного-то ?

есть массив, сначала делаю map, потом filter у кого есть примеры обхода массива один раз через редьюс ?

array.reduce(…) вроде все просто

есть массив, сначала делаю map, потом filter у кого есть примеры обхода массива один раз через редьюс ?

const customMap = (arr, cb) => arr.reduce((acc, key) => cb(key) ? acc.push(key) && acc : acc, []) Без андефайнда, ну там кароче сам поправишь так скозат еси че

есть массив, сначала делаю map, потом filter у кого есть примеры обхода массива один раз через редьюс ?

раз - https://www.google.ru/search?q=js+filter+and+map+together&oq=js+filter+and+map&aqs=chrome.1.69i57j0l5.5509j0j7&sourceid=chrome&ie=UTF-8 два - https://stackoverflow.com/questions/34398279/map-and-filter-an-array-at-the-same-time-in-javascript

const arr = [1, 2, 3, 4, 5]; const reduced = arr.reduce((p, c) => { if(p % 2 === 0) { return [...p, `hello, world ${c}`] } return p; }, [])

Сяп

const arr = [1, 2, 3, 4, 5]; const reduced = arr.reduce((p, c) => { if(p % 2 === 0) { return [...p, `hello, world ${c}`] } return p; }, [])

Я бы делал .concat

Я бы делал .concat

из-за читабельности ?

.filter(Boolean) не так страшен

из-за читабельности ?

Строки спредятся по одному символу

из-за читабельности ?

Из-за скорости

думаю, что на таких размерах это некритично )

думаю, что на таких размерах это некритично )

Ну да. С этого и начинаются тотальные тормоза (утрирую)

.filter(Boolean) не так страшен

reduce еще можно.

reduce еще можно.

Попробуй прочесть с чего тред начался

Ну да. С этого и начинаются тотальные тормоза (утрирую)

а сильно разница большая, кстати ?

а сильно разница большая, кстати ?

Да

из-за перебора первой коллекции ?

во время деструктуризации

reduce еще можно.

Там выше уже обсудили если чё

из-за перебора первой коллекции ?

Из-за пересоздания

Попробуй прочесть с чего тред начался

Вечная проблема того что люди не делают replay. Нихрена не понятно откуда начинается вопрос.

Вечная проблема того что люди не делают replay. Нихрена не понятно откуда начинается вопрос.

Ага, все виновны, но не ты )

Вечная проблема того что люди не делают replay. Нихрена не понятно откуда начинается вопрос.

Тоже бесит. Но тут не было нескольких параллельных тредов.

Там выше уже обсудили если чё

Если чё можно поиском найти ответы на все вопросы, за пол миллиона сообщений уже всё обсудили.

Если чё можно поиском найти ответы на все вопросы, за пол миллиона сообщений уже всё обсудили.

Ебать ты душный

Парни а какие щас топовые фреимворки типо material-ui

Из-за пересоздания

Иммутабельность же

Парни а какие щас топовые фреимворки типо material-ui

это не фреймворки, это ui-kits

это не фреймворки, это ui-kits

оу) сенк )

хочу отделить стор, вью и логику на три разных слоя чтобы можно было: - тестить логику без view вообще - тестить view отдельно от логики - менять логику без трогания view

Так это ж единственный верный путь, как еще делают то?) Точнее разве сейчас по-другому пишет кто-то?

Если чарты в админку, то https://github.com/recharts/recharts норм? Есть какие-то минусы у неё? (На другом проекте делал с chart.js, вроде было норм)

Парни а какие щас топовые фреимворки типо material-ui

https://github.com/artalar/blog/blob/master/src/pages/currently-best-ui-kits.md

Иммутабельность же

Там это не обязательно

Так это ж единственный верный путь, как еще делают то?) Точнее разве сейчас по-другому пишет кто-то?

Никто не может по настоящему логику отделить. По крайней мере я не видел

Никто не может по настоящему логику отделить. По крайней мере я не видел

FP, immutable, pure functions - заставят это сделать.

FP, immutable, pure functions - заставят это сделать.

Ты видимо сообщением ошибся

Потому что сейчас вообще мимо

Ты видимо сообщением ошибся

https://clip2net.com/clip/m34216/12fd6-clip-49kb.jpg?nocache=1 Ну, вот простой пример: - логика идёт отдельно в первой части кода (после импортов). Всё иммутабельно, pure functions - стор отдельно в createStore - вью отдельно после создания стора

https://clip2net.com/clip/m34216/12fd6-clip-49kb.jpg?nocache=1 Ну, вот простой пример: - логика идёт отдельно в первой части кода (после импортов). Всё иммутабельно, pure functions - стор отдельно в createStore - вью отдельно после создания стора

Где тут логика?

https://clip2net.com/clip/m34216/12fd6-clip-49kb.jpg?nocache=1 Ну, вот простой пример: - логика идёт отдельно в первой части кода (после импортов). Всё иммутабельно, pure functions - стор отдельно в createStore - вью отдельно после создания стора

Редюсер диспатчит?! Шштоо??

Где тут логика?

редьюсер = логика. селектор - логика

ERROR: S client not available

редьюсер = логика. селектор - логика

Блядь. Что??

Пиздец

Нет

Редюсер диспатчит?! Шштоо??

это лишь пример. Специально посторил пример, где сайд-эффект можно реализовать через редьюсер (знаю, что так лучше не делать)

Селектор это не логика. Это выбор данных из стора. Абстракция над структурой. Редюсер это апдейтер стора

Это вообще не логика

Никто не может по настоящему логику отделить. По крайней мере я не видел

Сейчас вышло так, что пишу приложение без интерфейса, дергаю танки из консоли) Интерфейс соотвественно нарисуют - надо будет прикрутить к стейту. Ты про что-то такое?)

Сейчас вышло так, что пишу приложение без интерфейса, дергаю танки из консоли) Интерфейс соотвественно нарисуют - надо будет прикрутить к стейту. Ты про что-то такое?)

Примерно. Только чтобы логика не была завязана на стор. А крутилась отдельно.

Селектор это не логика. Это выбор данных из стора. Абстракция над структурой. Редюсер это апдейтер стора

по задумке редакса редьюсер как раз описывает логику) Это уже энтузиасты решили всё из редакса повытаскивать и использовать его как общий EE

Например дебаунс событий делать в этом слое.

Делаю приложение на React / Redux / Redux-Saga. Интерфейс - консольный, написан на react-blessed. В принципе, приложение уже готово, и отлично работает. И вот возникла у меня мысль — а не запилить ли мне GUI-шную версию на Electron. В идеальном случае это будет просто замена слоя представления. У меня все компоненты достаточно чисты, поэтому мне надо будет просто запилить UI на обычном реакте, чтобы по-другому рендерить состояние стора. Но дьявол, как всегда в деталях. Нужен совет, как лучше в таком случае организовать репозиотрий. У меня сейчас сделан монорепо с помощью Lerna, и многие вещи лежат в отдельных npm-пакетах. Слой данных, слой кеширования, сторонний бинарник, итд. Но сама связка react-blessed / redux / saga — в одном npm-модуле. Запихивать CLI и Electron версии в один NPM-пакет что-то не особо хочется. Стоит ли мне вынести тогда в отдельный NPM-пакет всю логику без представляения? То есть редьюсеры, экшены, саги, селекторы и сервисы. Или плюнуть на всё — и скопипастить её в двух пакетах - в консольном приложении, в котором она сейчас и живёт, и в гуёвом — и пусть, типа, живёт двумя жизнями? P.S. приложение представляет собой музыкальный плеер.

по задумке редакса редьюсер как раз описывает логику) Это уже энтузиасты решили всё из редакса повытаскивать и использовать его как общий EE

Учитывая что всегда писали, что редюсер должен быть чистым и просто стор обновлять...

Селектор это не логика. Это выбор данных из стора. Абстракция над структурой. Редюсер это апдейтер стора

Вики: » Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области» (англ. domain logic). Проще говоря, бизнес-логика — это реализация предметной области в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д. « Редьюсер - это реализация предметной области (правил и ограничений автоматизируемых операций), нет? селектор - то же самое

Учитывая что всегда писали, что редюсер должен быть чистым и просто стор обновлять...

а что, логика не должна быть чистой?

Как раз вот оно, отделение логики от стора

Редьюсер грубо говоря не знает про стор никакой

Делаю приложение на React / Redux / Redux-Saga. Интерфейс - консольный, написан на react-blessed. В принципе, приложение уже готово, и отлично работает. И вот возникла у меня мысль — а не запилить ли мне GUI-шную версию на Electron. В идеальном случае это будет просто замена слоя представления. У меня все компоненты достаточно чисты, поэтому мне надо будет просто запилить UI на обычном реакте, чтобы по-другому рендерить состояние стора. Но дьявол, как всегда в деталях. Нужен совет, как лучше в таком случае организовать репозиотрий. У меня сейчас сделан монорепо с помощью Lerna, и многие вещи лежат в отдельных npm-пакетах. Слой данных, слой кеширования, сторонний бинарник, итд. Но сама связка react-blessed / redux / saga — в одном npm-модуле. Запихивать CLI и Electron версии в один NPM-пакет что-то не особо хочется. Стоит ли мне вынести тогда в отдельный NPM-пакет всю логику без представляения? То есть редьюсеры, экшены, саги, селекторы и сервисы. Или плюнуть на всё — и скопипастить её в двух пакетах - в консольном приложении, в котором она сейчас и живёт, и в гуёвом — и пусть, типа, живёт двумя жизнями? P.S. приложение представляет собой музыкальный плеер.

Опенсорс?

Только описывает логику того, как должно меняться состояние

setState асинхронный?

Опенсорс?

да

Только описывает логику того, как должно меняться состояние

Только логика немного сложнее чем обновление кусочка стора

Только логика немного сложнее чем обновление кусочка стора

Так происходит размазывание ровным слоем

да

Кинь ссылку, плиз

Примерно. Только чтобы логика не была завязана на стор. А крутилась отдельно.

Наверное это не работает, когда у нас логики представления больше, чем бизнес) Поэтому ты говоришь не видел норм разделения)

Вики: » Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области» (англ. domain logic). Проще говоря, бизнес-логика — это реализация предметной области в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д. « Редьюсер - это реализация предметной области (правил и ограничений автоматизируемых операций), нет? селектор - то же самое

Только ты намертво ее привязал к стору. А я не хочу этого

setState асинхронный?

Ребята

Наверное это не работает, когда у нас логики представления больше, чем бизнес) Поэтому ты говоришь не видел норм разделения)

Я близок к тому, чтобы изобрести подходящий способ

Только логика немного сложнее чем обновление кусочка стора

это уж где как

Как тру прогеры решают проблемы с ассинхронным обновлением setState ? Функция, которая вызывается после setState Дает старые данные.