Ну так пропами, пропами сударь.

Погодите.

hoc это новое название hof как у редакса, или именно <High><Low /></High>?

1

Хм..

А не легче ли второй вариант юзать тогда?

<Permissions list={['admin']}> <MyComponent /> </Permissions>

Получится что будет много обёрток

А так ты нужные тебе люди компоненты расширил и юзаешь как хочешь - с пермишенами или без

Ну если у тебя их много будет, тогда да. А так много оберток будет, но в другом месте.

А так ты нужные тебе люди компоненты расширил и юзаешь как хочешь - с пермишенами или без

Ну так а мой вариант чем отличается?

У тебя все равно целевой компонент остается без пермишенов.

В данном конкретном случае можно и так

Но в случае если придётся регулировать поведение компонента самого то придётся использовать hoc

Ну не то что придётся, но будет явно проще

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

А если он не нужен универсальный, то зачем вообще hoc тогда?

И обертка в принципе.

Чтобы функционал в одном месте хранить для разных компонентов

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

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

Погоди.

Регулируется извне, пропами штоле?

Ну да

Типо disabled на инпуте если прав нет?

Ну например да

А, сложил картину.

Угу, да. Тут подошло бы.

ребят подскажите так правильно делать ?

componentWillUpdate(prewState, newState) { const boolean = newState.schedules.length === 0 newState.disabled = boolean }

проверять массив с сервера и если он пустой вешать класс empty

prev*

Посмотри доку, менять стейт через componentWillUpdate нельзя. А так ты можешь тотже конструктор использовать для этих целей, если знаешь данные

но лучше в стейте считать

Посмотри доку, менять стейт через componentWillUpdate нельзя. А так ты можешь тотже конструктор использовать для этих целей, если знаешь данные

для каких целей тогда используют componentWillUpdate и componentDidUpdate для передачи данных на сервер ?

для совместимости с внешними библиотеками, которые не react-based

мне просто нужно менять класс в компоненте в зависимости от стейта

для взаимодействия с сервером есть другие средства

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

ну так завяжи класс на стейт в рендере

обычно я вообще наглухо отделяю публичные части от приватных

этот стейт зависит от другого

если пустой массив

а все понял

как можно называть константу/переменную boolean? это же путь канатаходца

is{Variable}

как можно называть константу/переменную boolean? это же путь канатаходца

is*, has*, does*

в смысле?

А кто как решает проблему супер-длинных экшенов?

А кто как решает проблему супер-длинных экшенов?

какую проблему?

А кто как решает проблему супер-длинных экшенов?

А что с ними не так

в смысле?

const isOpened = ... const hasChilds = ... const doesReceiveData = ...

а, ну это то да

ну, меня смущает ORDER_SHOW_PLACE_CONFIRM и ORDER_HIDE_PLACE_CONFIRM

но в примере выше const boolean = ...

их можно поменять на SET_ORDER_PLACE_CONFIRM_VISIBLE, но тоже хз

ну, меня смущает ORDER_SHOW_PLACE_CONFIRM и ORDER_HIDE_PLACE_CONFIRM

const types = createTypes(‘order’, [‘showPlace’, ‘hidePlace’]) dispatch({ type: types.showPlace })

isBoolean плохое название для переменной ?

ну, меня смущает ORDER_SHOW_PLACE_CONFIRM и ORDER_HIDE_PLACE_CONFIRM

redux-thunk, а внутри хоть час пусть висит

isBoolean плохое название для переменной ?

самое плохое, если это не парсер

их можно поменять на SET_ORDER_PLACE_CONFIRM_VISIBLE, но тоже хз

Можно на неймспейсы разбить, хз

redux-thunk, а внутри хоть час пусть висит

речь вообще о другом

А, понял

const types = createTypes(‘order’, [‘showPlace’, ‘hidePlace’]) dispatch({ type: types.showPlace })

да, смотрю

Да

const isDisabled = state.schedules.length === 0 ? 'button_out_of_call disabled' : 'button_out_of_call'

ERROR: S client not available

а так лучше ?

const isDisabled = state.schedules.length === 0 ? 'button_out_of_call disabled' : 'button_out_of_call'

нет

Суть не в redux-act, конечно

const isDisabled = state.schedules.length === 0 ? 'button_out_of_call disabled' : 'button_out_of_call'

const isDisabled = state.schedules.length === 0 const className = isDisabled ? 'button_out_of_call disabled' : 'button_out_of_call'

а вообще есть npmjs.com/classnames

Как без classnames жить вообще)

ну, меня смущает ORDER_SHOW_PLACE_CONFIRM и ORDER_HIDE_PLACE_CONFIRM

https://gist.github.com/LestaD/0ed933aa7174ae139dd6eb6016975119 6 строк и не нужен redux-act

Не, я ж говорю, суть не в redux-act, у меня просто код такой, я же его не выпилю теперь)

Не, я ж говорю, суть не в redux-act, у меня просто код такой, я же его не выпилю теперь)

ну да)) Способов сократить имена экшенов много)

Суть в том, что к константам я обращаюсь через неймспейсы) Экшн order —> import { ORDER } from 'action' ORDER.SHOW_PLACE и погнал

Суть в том, что к константам я обращаюсь через неймспейсы) Экшн order —> import { ORDER } from 'action' ORDER.SHOW_PLACE и погнал

любопытно, надо взять на заметку

а у нас экшены и редюсер в одном месте так что константы больше нигде не нужны

Облегчили написание констант, а апи целиком пишете

А вообще redux ducks каеф

Облегчили написание констант, а апи целиком пишете

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

работал кто нибуть с cloudinary ?

так а зачем ещё редюсер?))

Ну в принципе это можно в одну функцию уместить)

Но тогда ide не будет понимать что происходит, это минус

Ну в принципе это можно в одну функцию уместить)

впринципе можно и экшн один юзать)

ну да

как яндекс мапс

нет, не надо, только не это.

Не

redux-act сократит это до объекта с названиями пропертей

зачем this.extend?

редьюсеров тогда писать вообще не надо, но и контроль над экшенами остается

редьюсеров тогда писать вообще не надо, но и контроль над экшенами остается

почему просто не возвращать новый стейт? чистые функции, все дела

а это что-то странное