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

вот я хочу тоже самое, только ещё с возможностью простой вставки компонентов с внешних либ

Прототипирование не решит некоторых моментов. Например, где явная зависимость а где её инъекция должна быть.

не совсем понял кейс

вот я хочу тоже самое, только ещё с возможностью простой вставки компонентов с внешних либ

простой врятли выйдет

простой врятли выйдет

почему?

описать надо компоненты, как их импортить и откуда

То возможности генерации кода из прототипа очень-очень ограничены.

не совсем понял кейс

Ну, либо ты импортируешь один компонент из другого, либо ты его передаёшь в children.

И вот, система прототипирования усложнилась.

И сложность, по-моему, не очень явная.

всё равно не сильно понял пример(

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

точнее, что значит «импортирую один компонент из другого»?

точнее, что значит «импортирую один компонент из другого»?

<A><B />{props.children}</A>

всё равно не сильно понял пример(

У тебя на прототипе одна сущность будет внутри другой. Как ты опишешь, каким образом реализуется зависимость между ними?

У тебя на прототипе одна сущность будет внутри другой. Как ты опишешь, каким образом реализуется зависимость между ними?

children. я как раз не могу понять альтернативу

У тебя на прототипе одна сущность будет внутри другой. Как ты опишешь, каким образом реализуется зависимость между ними?

это не так сложно

children. я как раз не могу понять альтернативу

import MyComponent from 'my-component'

ииии?

как children связан с импортом?

*facepalm*

чаще всего компонент это композиция других компонентов

=)))

есть вот такая штука http://theprotein.io/

ты не отрендеришь просто так сторонный компонент

иии? передать что-то в компонент - это и есть children, нет?

правда это не совсем тоже самое и не уверен, что рабочее

иии? передать что-то в компонент - это и есть children, нет?

Короче, мне лень объяснять.

Не в этом суть.

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

есть вот такая штука http://theprotein.io/

че т не вижу где там и чего можно потыкать

если тебе не сложно - просто покажи пример рендера в случае с import’ом. я вообще не понимаю, причём тут импорт и рендеринг

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

у тебя есть компоненты A и B в разных файлах

Суть в том, что у нас уже 3 места, где мы что-то описываем: прототип, поведение, способы реализации зависимостей. Это будут вообще разные вещи.

А сейчас всё в одном месте.

у тебя есть компоненты A и B в разных файлах

и? это управление зависимостями, но никак не рендеринг

Это более понятно. Более просто. Более читабельно.

если тебе не сложно - просто покажи пример рендера в случае с import’ом. я вообще не понимаю, причём тут импорт и рендеринг

ты создаешь в редакторе компонент C render() { return <B><A foo="bar" /></B> } откуда ты возьмешь эти компоненты?

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

вооот

а если из сторонней библиотеки? а если из кода в твоём приложении?

Блин. =))

Если ты импортишь в этот компонент, это явная зависимость.

НЕ через children

Компонент С, например, явно зависит от A и B.

B рендерит в children A с пропсами но НЕЯВНО, потому что ему C прокинул внутрь

че т не вижу где там и чего можно потыкать

Там вроде бы все еще в бете

А то, что ты передал А в B — это иньекция зависимости.

Иньекция в контексте А и Б.

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

Там вроде бы все еще в бете

оно вроде еще в 2015 было, нет?

А то, что ты передал А в B — это иньекция зависимости.

решить это не слишком сложно при описании JSON компонента вытаскивать зависимости в списочек и потом генерировать но нахаваться столько можно кейсов разных

оно вроде еще в 2015 было, нет?

https://www.slideshare.net/moscowjs/react-moscowjs-27 ну да, после этого ничего не слышал

Я веду к тому, что такая "абстракция" только увеличит сложность.

Я веду к тому, что такая "абстракция" только увеличит сложность.

++

разработчикам особенно

а если из сторонней библиотеки? а если из кода в твоём приложении?

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

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

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

Ох...

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

Проблема в том, что он не уловил разницы пока.

я когда реализовывал кодогенерацию для своей штуки офигевал от сложности по резолвингу зависимостей

оно вроде еще в 2015 было, нет?

Но мне кажется, что они сейчас это пилят в Яндексе, т.к. двое точно перешли в Я, работать над архитектурой библиотеки компонентов

Вот, в чём разница. index.js import A from './a'; import B from './b'; export default () => <A><B /></A>; vs index.js import A from './a'; export default () => <A />; a.js import B from './b'; export default () => <B />;

ERROR: S client not available

Первое — А не зависит от Б. Используется внедрение зависимости. Второе — А железно зависит от Б. Но визуально (в прототипе) это выглядит как одно и то же. А твоё описание способа реализации зависимости будет неявным, и там легко будет допустить ошибку. ЛИБО. Создавать много-много прототипов разных компонентов. И запутаться в прототипах.

ты это кому?

Даниле. Долго писал. =)

жаль, что тг не подсказывает смайлы и стикеры по текстовым смайлам вроде :)

Я не очень жалую такие фичи. =) Так что, мне норм. А то от них потом всё свистит-пердит.

я был бы рад, on/off такой фиче

Мне недавно понадобилась фигня одна найти нигде не могу: Нужны панели на реакте, панели вроде как в IDE, перемещать можно по экрану, в панелях что-то размещать, изменять размер

мб кто видел?

Неа.

DIY?

я с трудом представляю как это реализовать на реакте ((

как хранить лэйаут

Ну, у тебя просто должна быть граница-кнопка, которю ты можешь таскать.

да это меньшая проблема ))))

Ну а за ней ресайзятся все лейауты.

а как хранить это в стейте?

сделать веса по шкале x и y, и высчитывать размеры по весу. типа как flexbox

Я бы сделал стейтфул компонент, общий. У него могут быть пропсы с конфигом, которые дублируются в своём стейте.

сделать веса по шкале x и y, и высчитывать размеры по весу. типа как flexbox

Проще фиксед рассчитывать на основании положения кнопки.

А потом создаём компонент ячейки и компонент "границы".

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

я думал проценты выставить и всё

я думал проценты выставить и всё

+ А, ну да.

просто не очень хочется переписывать https://github.com/atom/atom/blob/master/src/pane.coffee

Хотя тебе их, всё равно, придётся из координат кнопки высчитывать.

Хотя тебе их, всё равно, придётся из координат кнопки высчитывать.

это не так сложно

Вот, в чём разница. index.js import A from './a'; import B from './b'; export default () => <A><B /></A>; vs index.js import A from './a'; export default () => <A />; a.js import B from './b'; export default () => <B />;

а вот тут, во втором варианте, в index.js откуда берётся B?

а вот тут, во втором варианте, в index.js откуда берётся B?

вот именно) откуда?

а вот тут, во втором варианте, в index.js откуда берётся B?

Это хороший вопрос. =))))