https://github.com/ReactTraining/react-router/blob/master/packages/react-router-dom/docs/api/NavLink.md#exact-bool

спасиб!

RR4 странный

чем?)

Добрый день. что можете подсказать для работы с таблицами? Не хочу свой велосипед...

Добрый день. что можете подсказать для работы с таблицами? Не хочу свой велосипед...

excel ничего

-_-

Как сделать, что бы работало примерно так // actions/index.js const actions = { ...mastersActions, ...userActions, }; export default actions // import {someAction /* from userActions */} from 'actions';

RR4 мне нравится тем что там можно нестить роуты как хочешь :)

и разносить их по разным файлам

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

Vladyslav тут больше вопрос синхронизации этих значний

или так, кстати да, а как их можно синхронизировать ?

Меня вот тут осенило недавно. Редакс (и онные) используют как БД, в то время как это менеджер состояния...

Ну экшенами на какие либо события redux формы

Меня вот тут осенило недавно. Редакс (и онные) используют как БД, в то время как это менеджер состояния...

А разница

это стор, для хранения данных

состояние === данные

Народ кто нить пробовал в действии redux-pack ?

Стейт менеджеры созданы в первую очередь, что бы предоставить данные в одном месте не связанным компонентам, с подпиской(!) на эти данные. Тут ключевой смысл в подписке, а не в хранении. Конечно хранение - это классный бонус, но им стали злоупотреблять штуки вроде редакс форм. Используя редакс как БД мы получаем лишние обращения к подписанным компонентам при любом инпуте в эту БД. Это дико странно

Стейт менеджеры созданы в первую очередь, что бы предоставить данные в одном месте не связанным компонентам, с подпиской(!) на эти данные. Тут ключевой смысл в подписке, а не в хранении. Конечно хранение - это классный бонус, но им стали злоупотреблять штуки вроде редакс форм. Используя редакс как БД мы получаем лишние обращения к подписанным компонентам при любом инпуте в эту БД. Это дико странно

думаешь не бывает БД с подпиской?

Я глянул в одном из проектов индусских вполне себе успешных в их PWA. Единственный плюс увидел только в том, что можно все состояния типа success, fail, init и тд в одном месте прописывать. Этакая мини сага немного чтоли.

Как сделать, что бы работало примерно так // actions/index.js const actions = { ...mastersActions, ...userActions, }; export default actions // import {someAction /* from userActions */} from 'actions';

Я вообще за другим пришел =[

А еще pm2 кто нить юзает для запуска своих проектов локально без блокирования консоли?

pm2 - для локальной разработки фронтэнда?)

чтобы после обновления страницы или при прямом переходе на определенный роут оставаться на той же странице, только ssr поможет? RR v4

Не. Если это поддерживатеся на уровне платформы — базара ноль. Абсолютно ничего не имею против нативных промисов, или Option в rust-е.

Option в Rust не является частью синтаксиса языка, он задан в стандартной библиотеке вот так: enum Option<T> { Some(T), None }

Нет. Ни за чем он там не нужен. Можно абсолютно спокойно и безболезненно обойтись без него.

я от етого чуть не здох когда на кложуре писал

так что я не понял в чём разница между Option в Rust и Maybe в JS и что такое "поддержка платформой" если в обоих случаях всё средствами языка реализуется

есть у кого норм пример загрузки файлов ( картинки zip архив ) в base 64?

поддержка платформой это возможность создавать адт мб?

ну и всякие там удобства типо let binding, pattern marching

Народ кто нить пробовал в действии redux-pack ?

да, отл

ну и всякие там удобства типо let binding, pattern marching

ну это всё конечно круто, но в целом в большинстве случаев достаточно .map, .chain, .orElse и т. д.

а вот без ADT жить хуёво, да(

ну это всё конечно круто, но в целом в большинстве случаев достаточно .map, .chain, .orElse и т. д.

особенно когда у тебя много уровней где может быть ошибка

что решается do нотацией в большинстве случаев

так что я не понял в чём разница между Option в Rust и Maybe в JS и что такое "поддержка платформой" если в обоих случаях всё средствами языка реализуется

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

Блин, было бы можно описать тип у yield, вообще бы проблем не было

То есть »= вполне заменяется на yield

Но вот типизировать пока нельзя толком, в возвращаемом значении будет union от всех таких значений в функции

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

ну дело в том что альтернативы нет

ну дело в том что альтернативы нет

Ну так и клево же.

да

В js-е есть.

Не знаю, примерно это я и называю поддержкой со стороны платформы.

так что я не понял в чём разница между Option в Rust и Maybe в JS и что такое "поддержка платформой" если в обоих случаях всё средствами языка реализуется

в том что имея класс ты не можешь быть уверен что там внутри твориться

Не знаю, примерно это я и называю поддержкой со стороны платформы.

но ведь это и так часть платформы

в том что имея класс ты не можешь быть уверен что там внутри твориться

Если у тебя все поля read-only то просто не будет никакого "внутри"

но ведь это и так часть платформы

Кто? Maybe?

option

option

Ну да. В расте. В JS-е то нет.

но ты про поддержку со стороны платформы раста?

Ага. Не js-а же.

@eugeniyworld ну к примеру в PWA шке индусской для того чтобы типа в продакшн режиме локально запустить со всякими оптимизациями

Если у тебя все поля read-only то просто не будет никакого "внутри"

Кстати, не понятное утверждение. Они могут быть снаружи read-only, а изнутри вполне себе мутабельные.

Кстати, не понятное утверждение. Они могут быть снаружи read-only, а изнутри вполне себе мутабельные.

non sense, поля либо read-only либо нет

Я не про геттеры-сеттеры, а буквально, когда поля могут записать только один раз

non sense, поля либо read-only либо нет

Вообще не факт. Поле может быть определено как геттер из private\protected поля.

Я говорю, я не про этот случай

Очевидно, что можно вывернуться кучей способов, но я про случай когда никто нигде не выворачиватся, а readonly являются буквально тем, чем являются

Тогда всё становится проще и приятнее в обращении

Геттеры сеттеры кстати вообще не нужны По пальцам могу перечислить все случаи когда бы они мне были полезны, и все они были связаны с обходом костылей

Геттеры сеттеры кстати вообще не нужны По пальцам могу перечислить все случаи когда бы они мне были полезны, и все они были связаны с обходом костылей

Ну там инкапсуляция, все дела)

Геттеры сеттеры кстати вообще не нужны По пальцам могу перечислить все случаи когда бы они мне были полезны, и все они были связаны с обходом костылей

Раньше они были тормозные сильно и в ИЕ не поддерживались, поэтому не слишком распространены. А насчет нужны/не нужны — интересная дискуссия может быть, но в бест-практисах ООП они есть и даже считаются хорошим тоном.

ERROR: S client not available

Геттеры сеттеры кстати вообще не нужны По пальцам могу перечислить все случаи когда бы они мне были полезны, и все они были связаны с обходом костылей

За геттеры/сеттеры в 99 случаях из 100 надо по рукам бить

Раньше они были тормозные сильно и в ИЕ не поддерживались, поэтому не слишком распространены. А насчет нужны/не нужны — интересная дискуссия может быть, но в бест-практисах ООП они есть и даже считаются хорошим тоном.

Нет. Они считались бест практис лет 20 назад

Нет. Они считались бест практис лет 20 назад

Сильное утверждение. А можно типа ссылку на текущие актуальные бест практисы?

Геттеры и сеттеры это неочевидное поведение. Раньше было такое мнение что всякий сахар, скрывающий процессы происходящие в модуле - это самое то.

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

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

Потому человечество сделало богоподобную Джаву

Куда я попал ?

Джава богоподобная Сахар не нужен Вот ето вбросы

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

Ну, не знаю. Например, я пишу класс Canvas, который понятно что делает. И я определю у класса два сеттера — set width и set height, которые будут устанавливать размеры канваса.

Ну, не знаю. Например, я пишу класс Canvas, который понятно что делает. И я определю у класса два сеттера — set width и set height, которые будут устанавливать размеры канваса.

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

А когда ты используешь геттер/сеттер - ты этого совершенно не ожидаешь

Джава богоподобная Сахар не нужен Вот ето вбросы

Ну языка прозрачнее и очевиднее, чем джава, не сыскать

Потому что в большинстве случаев ты понятия не имеешь что там где-то используется геттер/сеттер

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

Именно поэтому в джаве нельзя переопределять операторы

В этом плане она богоподобна

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

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

В остальных, правда, так себе)))

Джава богоподобная Сахар не нужен Вот ето вбросы

Сахар нужен, но геттеры/сеттеры - нихуя не сахар

Именно поэтому в джаве нельзя переопределять операторы

ну паттерн геттеров/сеттеров он как раз из явы в существенной мере и там же сейчас и процесс их отмирания идет

ну паттерн геттеров/сеттеров он как раз из явы в существенной мере и там же сейчас и процесс их отмирания идет

Каким образом?

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

как насчет запретить изменять данные напрямую и разрешить только через методы?

народ

подскажите легкую либу для дропдаунов, модалок, селектов

ну паттерн геттеров/сеттеров он как раз из явы в существенной мере и там же сейчас и процесс их отмирания идет

Ну, так можно вообще докатиться, что все можно писать на голых процедурах.

алертов всяких попапов

алертов всяких попапов

material-ui.com ant.design

Сахар нужен, но геттеры/сеттеры - нихуя не сахар

Реактивность в Vue работает по этому принципу, и все хорошо

материал свои стили пихает везде

материал свои стили пихает везде

Ээ?

Да не пихает

Ну, так можно вообще докатиться, что все можно писать на голых процедурах.

Ну... Сейчас вообще такой тренд есть - процедурно-функциональный стиль с использованием ООП только для структуризации.