Не понял о каком наследовании идет речь, а так же последние абзацы, остальное кажется достаточно понятным, поехали.
Есть меню(не навигация, а просто набор плюшек, к примеру добавить заметку) и сама область где отображается эта заметка.
Почему этот "набор плюшек" не завязать на "навигации" ?
То есть "добавить заметку" -> /add, редактировать -> /edit/:id .. ? В любом случае, вы сами пишите о 2х областях, которые есть на всех страницах, значит у вас должен быть родительский компонент, в котором рендерится "шапка (меню это или нет, не важно) + рабочая область"
Получается, если вы все же за идею с роутером, то примерный код будет таким:
App.js...
<HeaderContainer /> // (или тупой <Header />)
{ this.props.children }
...
Внутри children, само собой разумеется - то, что возвращает ваш роутинг, значит, код роутера примерно такой:
...
<Route path='/add' component={AddContainer} />
<Route path='/edit/:id' component={EditContainer} />
...
Когда я говорю "контейнер", значит я подразумеваю (как и все остальные), что это компонент, который присоединен к redux ( то есть
connect(mapStateToProps,mapDispatchToProps)(имя_компонента)
).
Таким образом, мы уже решили вашу задачу про:
Меню при вызове запускает компонент конкретной задачи. тот отправляет результат на рабочий стол и там оно хранится , так как у нас в меню все сделано с помощью
Link из react-router'a, и наша рабочая область изменяется вместе с URL-адресом браузера. Если есть необходимость, все клики по меню "прогонять" через ActionCreators (AC) выполняя какие-то дополнительные действия, или просто "для порядка" - то вы можете использовать внутри ваших AC
push из react-router-redux, выглядит это обычно так:
dispatch(push('/newUrl'))
Если вы с реакт-роутером не хотите пример делать, то принцип все равно будет такой же, только вместо URL адреса, у вас должен быть другой признак, на основе которого будет создаваться рабочая область.
---
И еще. думаю вынести все данные(пункты меню к примеру) в отдельный файл(этакий недосервер)
Где с ним лучше общаться? использую react-redux
Определенно будете общаться в ваших функциях-создателях-действий, так как это же будет асинхронный запрос за json-файликом, а значит другого места быть не может. Если опустить правильные названия, то ваша область работы с файлом - actions.
---
Как уже сказано, в конце не пойму о чем вы пишите... Структура "ответа с сервера" ? или о чем речь? Зачем вам компонент, который будет приводить структуру в нужный вид? и тд.
---
Напоследок:
Да и мне примеры вовсе не нужны. хочу для начала своих шишек набить.
НО точно не хочу пару месяцев пилить проект(бесконечно усложняющаяся toDo) а потом понять что привык делать так как не надо.
Никакого привыкания "делать, как не надо" -
не бывает. Вы сначала делаете так, как считаете наилучше возможным, в процессе, что-то подпиливая, потом приходит озарение/совет - вы понимаете, что так будет лучше и делаете дальше. Если программист знает как "сделать лучше", но при этом делает "как привык" то грошь ему цена.
Простой
