это решается через рекурсию

ты в конце что получить хочешь?

вывод дерева данных

что-то похожего на это

http://www.codeproject.com/KB/aspnet/HierarchyTree/FamilyTree.JPG

вывод дерева данных

foreach используй и рекурсию с передачей вложенности

map тут не нужен

Хорошо, спасибо за подсказку.

тип у тебя есть функция renderTree - принимает массив

там через цикл проходит по всем элементам, создает ДОМэлементы, а потом вызывается для св-ва children у каждого элемента и так до самой последней вложенности

Хорошо, спасибо за подсказку.

Вот есть примеры, посмотри как у них это сделано: https://react.rocks/tag/TreeView

Все сводится к рекурсии как выше сказали, если есть children, рендеришь сам себя.

Выложил исходники react-app утилиты (для создания React приложений без конфигураций и скриптов для сборки) https://github.com/kriasoft/react-app

От фейсбука решение не подошло?

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

А в react-app много полезных вещей из коробки CSS Modules, PostCSS, Babel, Webpack, Browsersync, HMR, Hot React Loader и т.д.

Люди помогите,java изучаю застрял

Ильгар Агаев: Начиная с <<перенные и ссылки>> ,<<вызов функции и возвращаемое значение>>

Лучше бы консольную утилиту для создания компонентов

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

под саблайм например и выложить на гитхаб

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

?

Придётся самому скомпоновать из redux/mobx и ещё кучи штук :) Или написать самому.

Ну допустим взять стек который покрывает 70% случаев.

и генераторы компонентов чтобы были. Мб какой нить npm generate container MainPage

и ты никогда не попадаешь в эти 70% случаев )

тогда в каждом новом проекте не придется пересобирать все.

Ну, на фронте не знаю, на бэкенд стороне рельсы (ruby on rails) собрали довольно устойчивый стек. Может можно и под реакт так запилить.

Ангуляру же удается.

А тебе так трудно, штоле?

А тебе так трудно, штоле?

Я вроде читал что программисты ленивые и автоматизируют трудозатраты.

Не? )

у фронта задач много разных

Да согласен. Не факт что так вообще получится.

например, веб-приложения, либо обычные сайтики

Сделай себе seed-ревизиторий базовый, где есть штуки которые 100% везде нужны.

Вебпак там, структура, etc.

А потом дополняй. Что мешает то?

Сделай себе seed-ревизиторий базовый, где есть штуки которые 100% везде нужны.

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

Э

Ну это ты загнул.

Вебпак там, структура, etc.

мне тоже кажется, что в общую часть можно вынести конфигурацию по сборки и какую-то общую структуру + линтеры

Я такое разве что на рельсах с джанго и видел.

и генераторы компонентов чтобы были. Мб какой нить npm generate container MainPage

https://github.com/mxstbr/react-boilerplate форкни, если надо. Там есть cli вроде какой-то. Алсо, можешь форкнуть create-react-app от facebook или @koistya

А в остальном мире нет.

мне тоже кажется, что в общую часть можно вынести конфигурацию по сборки и какую-то общую структуру + линтеры

Можно, в отдельный npm-пакет приватный :)

А в остальном мире нет.

js очень динамично развивается.

Зачем в нпм пакет? Чтобы ставить зависимости, пока ты Ставишь зависимости?

Сегодня есть штуки которых буквально пару лет назад вообще не было.

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

Норм желание для средней по величине компании, на самом деле. Если она занимается продуктовой разработкой.

Предлагаю скооперироваться и запилить CLI для компонентов в проекте react-app

По-моему гит-сида достаточно.

Звучит как идея.

Зачем в нпм пакет? Чтобы ставить зависимости, пока ты Ставишь зависимости?

Чтобы ты мог реюзать в проектах

По-моему гит-сида достаточно.

Это одно из мнений. Тут есть как плюсы так и минусы.

Да я подсел на рельсы, признаюсь ? когда собирал фронт не хватало готовых штук, нужно все самому собирать.

Ну, просто такие вещи обычно делают тогда, когда проект не сделан еще вообще.

Структура там, папочки, конфиги. Не вижу как это можно поставить на живой проект через пакет.

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

Структура там, папочки, конфиги. Не вижу как это можно поставить на живой проект через пакет.

А у ангуляра как? я просто не смотрел ? но там же однотипная структура да?

Предлагаю скооперироваться и запилить CLI для компонентов в проекте react-app

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

Это все больше напоминает общение слепого с глухим.

Либо вы меня потеряли где-то. Либо я вас потерял.

В react-app планируется что CLI для создания новых компонентов, рутов и т.п. будет подбирать шаблоны из папки проекта если такие есть, а если нет использовать те что зашиты в react-app CLI утилиту

ERROR: S client not available

т.е. самое то, для использования в сущ. проектах

Сейчас все эти cli утилиты будут появляться как грибы после дождя :3 Что есть хорошо Хотя идеи всего этого витали давно и реализовывались у каждого где-то внутри компаний, чтобы хаос устаканить

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

О

Конфа отлагала.

спрос на генераторы а не бойлерплейты? определенно

Ну генератор тебе бойлерплейт и нагенерирует, не?

В react-app планируется что CLI для создания новых компонентов, рутов и т.п. будет подбирать шаблоны из папки проекта если такие есть, а если нет использовать те что зашиты в react-app CLI утилиту

збс ?

Другое дело, что надо избавляться от бплейта в принципе.

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

Ждём роботов, короче. Чтобы говоришь ему "хочу лендос как на макете". А он тебе код делает, и бек и фронт. А макет тоже роботом сделан. На основе рисунка начальника на бумаге.

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

Почему оверинжиниринг?

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

Моя позиция в том, что фреймворки это небольшое зло.

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

Это всё делается каждым по своему вкусу для своей компании.

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

ember?

Моя позиция в том, что фреймворки это небольшое зло.

На самом деле большое зло. Там есть плюсы и минусы. У нормального фреймворка минусов меньше и им вполне можно пользоваться.

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

ember?

Кстати надо посмотреть да ?

Да я не про то, что какой-то фреймворк плохой.

Я про то, что фреймворки (по крайней мере такие как Джанго или Рельса) навязывают свой собственный подход к разработке.

Почему оверинжиниринг?

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

Да, т.н. opinionated software.

С которым либо приходится мириться, либо включать онанизм в присядь.

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

понял тебя

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

@koistya а System.import через что сделан?

Если делать без ферймворков, да, на каждом проекте свой новый зоопарк, и надо привыкать. Зато полная свобода действий.

Я думаю для компаний которые делают типичные приложения фреймворки это плюс.

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

Ну так снипеет снипеетом. Но лучше editor agnostic. Кому надо - сделают потом свои шаблоны на проект или форкнут