Ребят, есть два приложения в связке React + Redux, мне нужно переиспользовать второе приложение внутри первого, при этом часть функций внутри второго приложения должна остаться, а часть будет прокинута через пропсы в него. Я думал выделить из второго приложения всё необходимое одним компонентом, и просто переиспользовать его в первом, но тогда в первом придётся дописывать определенный функционал из второго. Так вот вопрос заключается в том, как это лучше сделать и есть ли какие-нибудь примеры или статьи на эту тему?

Придется немного дописать, но общая схема такая: ты передаешь во второе приложение коллбэки, которые возвращаю тебе указатели на нужные тебе штуки (я хз что там у тебя), ловишь эти указатели в родительском компоненте и связываешь все воедино. Кактотак.

А я бы обернул все в стору и гонял бы через неё состояния, но это я

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

Придется немного дописать, но общая схема такая: ты передаешь во второе приложение коллбэки, которые возвращаю тебе указатели на нужные тебе штуки (я хз что там у тебя), ловишь эти указатели в родительском компоненте и связываешь все воедино. Кактотак.

А я бы обернул все в стору и гонял бы через неё состояния, но это я

Впринципе, да. Как вариант, можно застабать дочерний стор, чтобы он был всего лишь полем в родительском, но это придется переписывать <Provider />

https://github.com/ReactTraining/react-router/blob/master/packages/react-router/modules/MemoryRouter.js

И там combineReducers надо будет только перепилить + проброс компонентов

там есть такая штука, как MemoryRouter

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

Ну, вообще, больше выглядит как объект для рефакторинга. Если будешь такую клюкву без рефакторинга делать, то потом поддерживать станет невыносимо.

А вот с условиями все равно пичаль-бида. Тренарные операторы и условные выражения как-то не слишком читаемо выглядят.

Это шутка если что

А вот с условиями все равно пичаль-бида. Тренарные операторы и условные выражения как-то не слишком читаемо выглядят.

Ну, а что с ними не так? В реакте ведь этого нет скорее исторически, чем технически.

Ты смеешься?

Реакт это жс В жс if не возвращает значения. Поэтому и в реакте нет

Реакт это жс В жс if не возвращает значения. Поэтому и в реакте нет

Ну, типа, я как раз и размышлял, чтобы сделали что-нибудь типа виртуальных элементов, например: <if true> </if> <else> </else>

а как же a && b?

Ну, типа, я как раз и размышлял, чтобы сделали что-нибудь типа виртуальных элементов, например: <if true> </if> <else> </else>

Ну, типа, я как раз и размышлял, чтобы сделали что-нибудь типа виртуальных элементов, например: <if true> </if> <else> </else>

jsx-control-statements, плагин для бабеля

jsx-control-statements, плагин для бабеля

Это не совсем то

Ну, типа, я как раз и размышлял, чтобы сделали что-нибудь типа виртуальных элементов, например: <if true> </if> <else> </else>

тебе в vuejs

По-моему проще разрежить делать return и любые statement-ы в jsx-е, чем вносить пропозал в язык.

Кстати, это вполне достижимо, если писать {() => { return <div /> }}

Ну не на jsx же свет клином сошёлся

Ну, в пропозале один из примеров приводится именно для него. Подозреваю, что ради этого все и затевалось.

Создавать функцию в рендере, норм ли это?

Vue на самом деле очень хорошая библиотека, кто бы что ни говорил. Она мне еще понравилась в 2014 году, когда был в ходу IE8, почему мы не удалось ее заюзать в проекте. Но проблема у нее одна — слишком много мутабельности. С реакта, конечно, на vue смысла нет переходить, а вот с других библиотек — нормально.

> Но проблема у нее одна — слишком много мутабельности. С чего это мутабельность стала проблемой?

Отлаживать сложнее

> Но проблема у нее одна — слишком много мутабельности. С чего это мутабельность стала проблемой?

> Но проблема у нее одна — слишком много мутабельности. С чего это мутабельность стала проблемой?

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

Это да :(

Вот этим, собственно, реакт и приколен. Все остальное — это скорее недостатки -)

в какой ситуации мобХ будет лучше редакса на ваш взгляд? когда стор слишком сложный ?

Прикольнинько https://www.npmjs.com/package/babel-plugin-jsx-control-statements

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

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

Нет

Два котика

пардоньте, исправил

Нет, не одного. Вообще почему-то только во фронтенде люди так неровно дышат в сторону всякого ФП. Во всяких бэкенда мутации на мутациях и мутациями погоняют. И ООП во все поля. И ничего, никто от этого не умер.

Нет, не одного. Вообще почему-то только во фронтенде люди так неровно дышат в сторону всякого ФП. Во всяких бэкенда мутации на мутациях и мутациями погоняют. И ООП во все поля. И ничего, никто от этого не умер.

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

Пойду скажу это нашей хаскелистке или эликсирщику

любой ui сильно сложнее бекенда

А такие есть вообще?

Вокруг меня сидят.

любой ui сильно сложнее бекенда

покажи хасткелистку )

Не думаю что она согласится, лел

))))))))

Говорят что фронтенд ныне не про подключение жквери плагинчиков

любой ui сильно сложнее бекенда