зато иногда доставляют фичи быстрее чем в самом react-native, например useNativeDriver
ну с этим ничего не скажу, по своему проекту понимаю что лучше минимум магии, и больше поддержки нативных решений.
Энлов Свичблейд
Энлов Свичблейд
Если нет девелоперского акка на apple, а тестить хочется, expo очень даже подходит
Dima
слово нативных немного обесценено, уже не до конца понимаю
Энлов Свичблейд
Но нативные библиотеки просто Нипоставить
Dima
ну если доходишь до этого момента и нет выбора - выходишь из контейнера
Dima
но каждая нативная библиотека - доп. боль. Набор который там идет он тестируется на совместимость, а так будь готов форкать постоянно и править. Но да, для многих приложений выбора нет
Энлов Свичблейд
слово нативных немного обесценено, уже не до конца понимаю
Например java библиотеки по работе с pdf, или ios framework QuickLook
Dima
ну да, всё так
Alex
какой профит от Typescript в React Native? Тут есть кто работает с Typescript в RN?
Anonymous
присоединюсь к вопросу
Джон
но каждая нативная библиотека - доп. боль. Набор который там идет он тестируется на совместимость, а так будь готов форкать постоянно и править. Но да, для многих приложений выбора нет
и не только нативная, вроде как ) все они боль немного
Aleksei
какой профит от Typescript в React Native? Тут есть кто работает с Typescript в RN?
такой же как и все стат типизированные языки дают тем кто в них верит)
Владимир
// и пользуются vscode
Vladimir
Тут есть гуру нативных компонентов?
Vladimir
Ну или не гуру, а просто в теме
Vladimir
Короче, вкину вопрос, может кто знает
Vladimir
Нужно сделать метод на инстансе нативного компонента
Vladimir
В iOS сделал через self.bridge.uiManager addUIBlock:
Vladimir
Соотвественно в метод передается findNodeHandle() первым аргументом
Vladimir
Дальше стал разбираться, как это сделать в Андроиде
Vladimir
В итоге оказалось что можно сделать примерно так же:
Vladimir
getReactApplicationContext().getNativeModule(UIManagerModule.class).addUIBlock
Vladimir
Все работает
Vladimir
Но почему то и в самом реакт найтиве и в некоторых пакетах это не используется
Dmitry
Есть
Dmitry
какой профит от Typescript в React Native? Тут есть кто работает с Typescript в RN?
Vladimir
А вместо это используется receiveCommand
Vladimir
Соотвественно вопрос - почему так?
Vladimir
Вот пример: https://github.com/mapbox/react-native-mapbox-gl/blob/master/index.js#L41-L61
Vladimir
Непонятно, зачем такой геморрой, если можно сделать абсолютно точно так же
Dmitry
Ну меньше пишешь багов, есть норм автокомплит, d.ts файлы довольно распространены, они заменят тебе доку
Alex
andrei
как подключить вебпак или как сделать алиасы для модулей без него? (нашел в чате какой-то @providesModule, выглядит костыльно)
Alex
Богдан
Народ, как тестите mocha?
Богдан
Валит ошибку Unexpected token import (react-native-svg-uri/index.js)
Богдан
Конфиг как по ссылке: https://medium.com/@childsmaidment/testing-react-native-components-with-enzyme-d46bf735540#.yvej8y6me
Богдан
Рили оч нужна помощь
Владимир
Я забил и кармой через вебпак стал собирать
Богдан
Основная проблема - expo
Богдан
Проект на нем стоит
Джон
как подключить вебпак или как сделать алиасы для модулей без него? (нашел в чате какой-то @providesModule, выглядит костыльно)
https://www.npmjs.com/package/babel-plugin-module-alias
Oleg
такой же как и все стат типизированные языки дают тем кто в них верит)
> Тем кто в них верит
А ты веришь в гору в ручную написанных тестов? )
Oleg
а в чем Профит?)
Профит в том что компилятор за тебя тестирует код. Это, конечно, не гарантирует корректность программы. Но снижает варианты опечаток драматически(я в это верю, правда, @savelichalex ;/) )
Aleksei
Профит в том что компилятор за тебя тестирует код. Это, конечно, не гарантирует корректность программы. Но снижает варианты опечаток драматически(я в это верю, правда, @savelichalex ;/) )
ну это больше мое имхо наверно, как по мне трудозатраты на написание типов в программе слишком большие, учитывая что тесты все равно писать надо 🙂
Oleg
Статическая строгая типизация помогает поддерживать огромные кодовые базы. Чего не скажешь про динамическую слабую.
Компилятор подсказывает где и что именно ты упустил, с динамической типизацией ты узнаешь это только после тестового прогона(да, обложи все тестами), если сам не заметил. То есть скорость разработки увеличивается, на больших проекта.
На маленьких проектах статическая типизация большого смысла, неверное, не придаст.
Тесты нужны и тесты важны. Но не во всех кусках кода. Тестировавать нужно алгоритмы. Тестировать параметры и способность функции/метода/класса и тд к полиморфизму или просто на корректную обработку очевидно некорректных аргументов — слегка overkill.
andrei
https://www.npmjs.com/package/babel-plugin-module-alias
Не очень удобный конфиг, я пробовал https://www.npmjs.com/package/babel-plugin-resolver, но он не работал, видимо придется этот использовать
Hey
expo это уже мастхэв?
Hey
это хорошая новость
Vladimir
Oleg
Можно обойти не используя их инфраструктуру. Но тогда вопрос: зачем они нужны?
Aleksei
Статическая строгая типизация помогает поддерживать огромные кодовые базы. Чего не скажешь про динамическую слабую.
Компилятор подсказывает где и что именно ты упустил, с динамической типизацией ты узнаешь это только после тестового прогона(да, обложи все тестами), если сам не заметил. То есть скорость разработки увеличивается, на больших проекта.
На маленьких проектах статическая типизация большого смысла, неверное, не придаст.
Тесты нужны и тесты важны. Но не во всех кусках кода. Тестировавать нужно алгоритмы. Тестировать параметры и способность функции/метода/класса и тд к полиморфизму или просто на корректную обработку очевидно некорректных аргументов — слегка overkill.
вот про строгую vs слабую это ты точно подметил) но чтобы компилятор тебе подсказывал, тебе для начала нужно еще ему объяснить, что где и как. ну и просто наличие стат типизации ни о чем не говорит, она тоже бывает разная, все мы знаем про NPE) ну и большие проекты нужно делить на артефакты, тогда и тестировать проще, и проект понимать проще) а насчет тестов, кмк гораздо важнее интеграционные чем юниты, и конечно же не нужно проверять каждую функцию.
Oleg
вот про строгую vs слабую это ты точно подметил) но чтобы компилятор тебе подсказывал, тебе для начала нужно еще ему объяснить, что где и как. ну и просто наличие стат типизации ни о чем не говорит, она тоже бывает разная, все мы знаем про NPE) ну и большие проекты нужно делить на артефакты, тогда и тестировать проще, и проект понимать проще) а насчет тестов, кмк гораздо важнее интеграционные чем юниты, и конечно же не нужно проверять каждую функцию.
Unit тесты хорошо писать для алгоритмов. Они важны в ряде случаев. Соглашусь на счет приоритета интеграционных
Aleksandr
Ребят, кто использует mobx в своих проектах, расскажите как ощущения? По сравнению с редаксом
Andrew Efimenko
Igor
Есть мнение, что mobx близок тем, кто любит oop. А redux тем, кто любит функциональщину.
Vladimir
Редукс и функциональщина слабо клеятся
Igor
Mobx прекрасен, внутри магия. Но в некоторых случаях были сложности с дебагом.
Владимир
mobx
Vladimir
Ну функциональщина это когда чистые функции
Vladimir
Когда ты вызываешь dispatch или делаешь запрос к АПИ, функциональщина в редуксе заканчивается
Владимир
мобикс прекрасен
Aleksei
Ну функциональщина это когда чистые функции
не только haskell функциональщина) фп это про композицию функций прежде всего, просто чистые функции легче композировать
Владимир
не знаю насчет ооп, в мобиксе можно разбить все на сторы и экшны, и работать в функциональном стиле
Владимир
ну в таком, полуфункциональном
Vladimir
Да не, функциональщиной в редуксе и не пахнет
Vladimir
Вообще это и не нужно
Vladimir
Это не мнение, это по определению
Vladimir
Опять же, как это не назови, менять это ничего не меняет
Hey
о беспонтовый холивар
Vladimir
Да как бы и в документации самого редукса это написано