монорепа это не про то же?

про это

проект с 10 разными конфигами превращается в адский ад зависимостей и однажды в продакшн улетит дебаг-сборка)

Щас бы выкатывать в прод непротестированную сборку

мы хотим всё по феншую настроить, СI, CD и тп

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

ты думаешь те у кого дебаг в прод улетал как-то по другому делали и хотели?)

Если проект с нуля - TS однозначно. Если уже много написао - Flow легче подключить.

не верно, послушайте Илью Климова, почему если Angular то TypeScript , если React, то Flow https://youtu.be/9_GwX9O6DFE

Всем привет, можете рекомендовать платежных систем. Хотел юзать страйп, но там ограниченное количество стран

Есть https://fondy.ru но у них либа под React-Native месяц назал была устаревшей с новыми версиями. Можно попробывать самому обновить. Ну или лучший вариант юзать эту либу. https://github.com/naoufal/react-native-payments

не верно, послушайте Илью Климова, почему если Angular то TypeScript , если React, то Flow https://youtu.be/9_GwX9O6DFE

Головой надо думать, а не Илью слушать. Писал на ts под rn - не было проблем (в итоге конечно бросил, ибо типы не спасают от убогости жс).

Головой надо думать, а не Илью слушать. Писал на ts под rn - не было проблем (в итоге конечно бросил, ибо типы не спасают от убогости жс).

А умом, в той голове, думать можно, слушая Илью??

Просто я хочу сказать что разницы то нет flow или ts (теорема эскобара ?)

Просто я хочу сказать что разницы то нет flow или ts (теорема эскобара ?)

Чат то у нас React-Native, а он на JS и многие им довольны. Предлагаете бросить его и на чем писать?

Чат то у нас React-Native, а он на JS и многие им довольны. Предлагаете бросить его и на чем писать?

Дык если чат по RN, уже другие языки, на которых можно под него писать, уже обсуждать нельзя?

Чат то у нас React-Native, а он на JS и многие им довольны. Предлагаете бросить его и на чем писать?

ReasonML / F# / ClojureScript - на них всех можно Для любителей сишного синтаксиса есть dart/scalajs

Чат то у нас React-Native, а он на JS и многие им довольны. Предлагаете бросить его и на чем писать?

Ну и как бы JS далеко не самый идеальный язык, альтернативы стоит рассматривать, имхо

Дык если чат по RN, уже другие языки, на которых можно под него писать, уже обсуждать нельзя?

Дык терли уже это здесь)) t.me/reactnative_ru/47347

Дык терли уже это здесь)) t.me/reactnative_ru/47347

А, то есть если фб что-то юзает, то это уже идеальный выбор и все, больше думать не надо?

ризон точно в топку

Не стоит слепо следовать авторитету

они уже из него бяку сделали

А, то есть если фб что-то юзает, то это уже идеальный выбор и все, больше думать не надо?

@angmarr почему на Ваш взгляд Facebook выбрал JavaScript, а не ReasonML / F# / ClojureScript ? Ответ на этот вопрос еще не слышал)

@angmarr почему на Ваш взгляд Facebook выбрал JavaScript, а не ReasonML / F# / ClojureScript ? Ответ на этот вопрос еще не слышал)

Потому что у них куча жс-разрабов, вот и все

Нужен был инструмент с минимальным порогом вхождения - они его сделали

им проще жс дописать под свои нужды

Потому что у них куча жс-разрабов, вот и все

Почему много где куча JS разарботчиков? Зачем крупные компании мучают себя?

Почему много где куча JS разарботчиков? Зачем крупные компании мучают себя?

Ангулярщики не мучают :)))

@angmarr почему на Ваш взгляд Facebook выбрал JavaScript, а не ReasonML / F# / ClojureScript ? Ответ на этот вопрос еще не слышал)

эм, fb вообще то reason ml и сделали)

Ангулярщики не мучают :)))

))))

А вообще - потому что все привыкли, инструментария полно под жс, вот все на нем и пишут

А на тс какие-то классы, еще изучать их, зачем, если можно тяп-ляп на жс и готово

эм, fb вообще то reason ml и сделали)

почему эти языки не под капотом React-Native?

не согласен, просто на js-е проще делать либы, из-за интеропа

не согласен, просто на js-е проще делать либы, из-за интеропа

что за интероп?

почему эти языки не под капотом React-Native?

исторически так сложилось. fb это не команда из 5 человек, там много людей работает, когда делали RN то reason-а еще и в помине не было

@angmarr почему на Ваш взгляд Facebook выбрал JavaScript, а не ReasonML / F# / ClojureScript ? Ответ на этот вопрос еще не слышал)

Ой не надо начинать... Короче поинт был - не делить flow/react vs typescript/only-angular Дальше спорить смысла нет Вообще можно и на ванильном писать, VSCode все равно ts-биндинги подгрузит ? и подсказки будут +-

что за интероп?

))))

исторически так сложилось. fb это не команда из 5 человек, там много людей работает, когда делали RN то reason-а еще и в помине не было

а уж переписывать «просто так» это не в стиле fb, да и вообще не инженерная практика

исторически так сложилось. fb это не команда из 5 человек, там много людей работает, когда делали RN то reason-а еще и в помине не было

Почему Sebastian Markbadge сказал, что мы будем добавлять в React только то, что будет проходить спецификацию Ecma TC39 https://github.com/tc39 С чем это может быть связано?

Почему Sebastian Markbadge сказал, что мы будем добавлять в React только то, что будет проходить спецификацию Ecma TC39 https://github.com/tc39 С чем это может быть связано?

с тем что он в коммитете?)

Народ, а AsyncStorage в симуляторе норм работает? Что-то не сохраняет

Пишу на TS под RN уже три года, полет нормальный. Считаю, что flow vs TS чисто эстетический выбор.

Почему Sebastian Markbadge сказал, что мы будем добавлять в React только то, что будет проходить спецификацию Ecma TC39 https://github.com/tc39 С чем это может быть связано?

Типа если он такой крутой и сказал, то все, это истина в последней инстанции?

))))

Что Вы Илья, я же учусь))

Народ, а AsyncStorage в симуляторе норм работает? Что-то не сохраняет

было бы еще неплохо уточнить android или ios)

симулятор значит ios ;)

ой, на RN год, еще до этого два на реакте

было бы еще неплохо уточнить android или ios)

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

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

ну у меня да))

он по идее просто в файл пишет, так что не должно быть проблем

Ммм а окей, поищу файл значит

Народ, а AsyncStorage в симуляторе норм работает? Что-то не сохраняет

Точно работает. Мы на проекте используем и тестить приходится в симуляторе

@dandelio о привет)

Привет-привет. Узнал таки)))

тусовка питерская

тусовка питерская

Да тут похлеще вышло. Одногруппники мы

Фигак одногрупник

Фронтенд объединяющий

@savelichalex

^^

Чота не по теме спамер влез

Чота не по теме спамер влез

+1 давайте банить

что за интероп?

@savelichalex ?все же что за интероп? ?

@savelichalex ?все же что за интероп? ?

interoperate. в общем то как функу из одного языка вызвать в другом. почти все языки которые таргетятся в js могут вызывать js-ные либы, обратное уже увидеть гораздо сложнее

interoperate. в общем то как функу из одного языка вызвать в другом. почти все языки которые таргетятся в js могут вызывать js-ные либы, обратное уже увидеть гораздо сложнее

понятно! а то гугление впервые не дало результата)

как получить название собственного приложения внутри компонента?

у меня jest ругается на импорт react-native-elements кто нибудь знает как пофиксить? testFileNode.setOutcome is not a function тип того пишет

как получить название собственного приложения внутри компонента?

забинди в константы

забинди в константы

пока так и делаю

думал может можно выцепить из конфигов

думал может можно выцепить из конфигов

можно потанцевать с бубном и написать метод на нативе наверное, если так сильно надо)

пусть в константах тогда живет

Или на крайняк импортируй package.json и бери оттуда.

у меня jest ругается на импорт react-native-elements кто нибудь знает как пофиксить? testFileNode.setOutcome is not a function тип того пишет

нид хелп) может как то можно заимпортить хитро можно? if (typeof process !== 'undefined' && process.env && process.env.NODE_ENV != 'test') import {Icon} from 'react-native-elements'; так не работает)

Вопрос больше про React, но всё же: как сделать так, чтобы при ошибке валидации props компонент не рендерился вообще?

https://t.me/react_js

shouldComponentUpdate(nextProps, nextState) { return false; }

Этот метод не срабатывает же перед первым рендером

componentWillMount

но вообще мне кажется, лучше сделать render(){ if(!this.isValidProps()){ return null; } }

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

опять же получается двойная валидация - сначала в пропсах, потом в рендере

не, только в рендере

вообще валидация - недорогая операция скорее всего

Или на крайняк импортируй package.json и бери оттуда.

мне казалось что это не тру вей)

не, только в рендере

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

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

они и не нужны, если тс юзать:)

но вообще мне кажется, лучше сделать render(){ if(!this.isValidProps()){ return null; } }

Что за компонент? Если это какой-то внутренний, то почему не проверить у родителя, прежде чем отрисовать его? Ну и + shouldComponentUpdate.

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

Как раз не увидишь ошибку

в консоли увидишь

Что за валидаторы в пропсах? Я что-то вообще не могу понять о чем речь)))

Надо исключения кидать или console.error

propTypes

А проптайпс

короче есть ассерты, а есть бизнес-логика