Комментарии 33
Вы правда считаете нормальным тьюринг-полный язык пытаться транслировать в тьюринг-неполный? Проще и надёжнее действовать в обратном направлении.
Так вот, операции над входными параметрами, которые проводились в JSX будут переведены в TS.
Так, например, мутации перед итерации с массивом элементов — изначально выдернуты и не отображаются в результируюзем html-шаблоне. Эти операции будут вынесены отдельно в TS.
Над этим я прямо сейчас работаю
Проблема тут именно в различии самого способа рендера в реакте и в ангуляре.
Лучше уж подождать нового рендера и попробовать генерить уже скомпиленные темплейты, а не сами ангуляровские. Это должно быть сильно проще.
Новый рендер не отменяет того, что сами архитектуры кардинально отличаются, и существенной разницы не будет
В самом рендере архитектура очень близка как раз, просто темплейты от этой архитектуры эффективно пользователя изолируют. Но для текущего рендера руками генеить код малореально, а вот в ivy будет в принципе вполне ок.
Возможно, конвертировать HOC'и в сервисы.
Посмотрим
Скорее всего оптимальным решением будет написание под каждый специфичный HOC специфичный конвертер.
Так же, это может быть крайне полезно при миграции с одного фреймворка на другой.
и в Retail продуктах для админ-панелей мы используем React.JS в качестве основного фреймворка, однако платформа для ресторанов использует Angular, что не позволяет им использовать нашу библиотеку компонентовА вы не задумывались о том, чтобы использовать React-компоненты в Angular? Будут сложности с трансклюдом правда. Но мне почему-то кажется, что это вполне реально.
<li *ngFor="let asd of a">{{asd}}</li>
По хорошему, нужно генерировать так же trackBy функцию (соответствует key-аттрибуту в реакте), чтобы не огребать на ровном месте. А вам нужна единоразовая генерация или мультиразовая?
Про ключи — да, я выдергиваю это, в целом, trackByFn — это ReturnStatement с содержимым аттрибута key.
Конечно же мультиразовая :)
Конечно же мультиразовая :)Грустно, на самом деле. Придется либо постоянно дописывать конвертер, либо очень лимитировать разработчиков. Частный случай решить проще. Как задача интересно, но поддерживать это — я бы на такое не подписался.
Т.е. если у вас вдруг появилась конструкция, которая ранее не встречалась — новый предикат и генератор, проблема решена.
Именно поэтому я и написал про статический анализатор предметов, чтобы в процессе написания нового видеть возможные пересечения. В конце-концов всегда можно переопределить другой или написать более специфичный предикат
А как планируете различать Input и Output?
Output не используется в рендере, грубо говоря, он ничего не возвращает.
Более того, мы знаем, что самое частое использование аутпута —
this.props.*(someData?)
Т.е., это функция, результат которой не используется в JSXExpressionContainer'е как таковом(не является чайлдом)
<input onChange={e => props.setName(e.target.value))}></input>
Или вы про то, что для событий явно не будет такого?
<custom strangAttr={props.getSmth()}></custom>
Возможны ситуации с пробросом обработчиков событий через 2-4 компонента.
<custom-button onClick={props.showPopup}></custom-button>
И еще один важный момент. В реакте обработчики кастомных событий могут спокойно возвращать какой-то результат (правда хз зачем, но можно). А в ангуляре это невозможно — EventEmitter не даст вам этого сделать.
С другой стороны в некотором реактовском коде можно также встретить передачу функции как параметризацию компонента (что можно перенести напрямую в ангуляровский код). Это пример 2 из этого комментария.
onChange={e => callExpression}
setName — параметр из props, мы изначально можем сказать, что это функция — Output.
Проброс — так же весьма интересный вариант. Дело в том, что проброс — это не вызов :) А значит — инпут :)
Носите preact или любую другую легковесную реализацию. На реакте свет клином не сошёлся.
Слегка не по теме вопрос — я увидел что вы генерируете типы, и подумал — давно хотелось генерировать рандомные объекты по их ts-интерфейсам и использовать их для упрощения юнит-тестирования, но нет никакой возможности получить доступ к свойствам интерфейсов — на этапе компиляции ts в js типы растворяются. Не знаете ли вы, можно ли использовать один из этапов ts-компиляции для того чтобы схватить список свойств интерфейса?
Вопрос к автору: как успехи с этим проектом? Получилось ли что-то серьезное мигрировать?
Конвертация React в Angular с использованием универсального абстрактного дерева. Proof of Concept