Comments 33
Вы правда считаете нормальным тьюринг-полный язык пытаться транслировать в тьюринг-неполный? Проще и надёжнее действовать в обратном направлении.
Это вы сейчас про JSX -> Angular Template?
Так вот, операции над входными параметрами, которые проводились в JSX будут переведены в TS.
Так, например, мутации перед итерации с массивом элементов — изначально выдернуты и не отображаются в результируюзем html-шаблоне. Эти операции будут вынесены отдельно в TS.
Над этим я прямо сейчас работаю
Так вот, операции над входными параметрами, которые проводились в JSX будут переведены в TS.
Так, например, мутации перед итерации с массивом элементов — изначально выдернуты и не отображаются в результируюзем html-шаблоне. Эти операции будут вынесены отдельно в TS.
Над этим я прямо сейчас работаю
Ну смотрите, допустим конструкции вида?: из jsx вы еще сконвертируете в *ngIf. но например вывести список компонент в реакте можно десятком различных способов, вы будете все описывать? А может там вместо списка будет просто произвольная функция. Определить, что она возвращает — задача алгоритмически неразрешимая.
Проблема тут именно в различии самого способа рендера в реакте и в ангуляре.
Лучше уж подождать нового рендера и попробовать генерить уже скомпиленные темплейты, а не сами ангуляровские. Это должно быть сильно проще.
Проблема тут именно в различии самого способа рендера в реакте и в ангуляре.
Лучше уж подождать нового рендера и попробовать генерить уже скомпиленные темплейты, а не сами ангуляровские. Это должно быть сильно проще.
Новый рендер не отменяет того, что сами архитектуры кардинально отличаются, и существенной разницы не будет
> Новый рендер не отменяет того, что сами архитектуры кардинально отличаются, и существенной разницы не будет
В самом рендере архитектура очень близка как раз, просто темплейты от этой архитектуры эффективно пользователя изолируют. Но для текущего рендера руками генеить код малореально, а вот в ivy будет в принципе вполне ок.
В самом рендере архитектура очень близка как раз, просто темплейты от этой архитектуры эффективно пользователя изолируют. Но для текущего рендера руками генеить код малореально, а вот в ivy будет в принципе вполне ок.
UFO just landed and posted this here
А как НОС'и транслировать?
HOC'и — отдельная история, как и React.cloneElement.
Возможно, конвертировать HOC'и в сервисы.
Посмотрим
Возможно, конвертировать HOC'и в сервисы.
Посмотрим
HOC много мощнее чем все что есть в Angular.
Скорее всего оптимальным решением будет написание под каждый специфичный HOC специфичный конвертер.
Скорее всего оптимальным решением будет написание под каждый специфичный HOC специфичный конвертер.
В конечном счете, можно прямо-таки переносить функционал HOC'а в сам компонент.
В AoT-режиме ангуляра с выкинутым компилятором шаблонов у вас не получится такой трюк. Просто потому что HoC может трансформировать vDOM таким образом, что вам придется генерировать компоненты в рантайме.
Воу, это выглядит как очень интересная задача в техническом плане!
Так же, это может быть крайне полезно при миграции с одного фреймворка на другой.
Так же, это может быть крайне полезно при миграции с одного фреймворка на другой.
и в Retail продуктах для админ-панелей мы используем React.JS в качестве основного фреймворка, однако платформа для ресторанов использует Angular, что не позволяет им использовать нашу библиотеку компонентовА вы не задумывались о том, чтобы использовать React-компоненты в Angular? Будут сложности с трансклюдом правда. Но мне почему-то кажется, что это вполне реально.
<li *ngFor="let asd of a">{{asd}}</li>А вам нужна единоразовая генерация или мультиразовая?
Использовать react-компоненты в ангуляре — нести с собой реакт, что не очень. К тому же, цель — иметь нативные компоненты.
Про ключи — да, я выдергиваю это, в целом, trackByFn — это ReturnStatement с содержимым аттрибута key.
Конечно же мультиразовая :)
Про ключи — да, я выдергиваю это, в целом, trackByFn — это ReturnStatement с содержимым аттрибута key.
Конечно же мультиразовая :)
Конечно же мультиразовая :)Грустно, на самом деле. Придется либо постоянно дописывать конвертер, либо очень лимитировать разработчиков. Частный случай решить проще. Как задача интересно, но поддерживать это — я бы на такое не подписался.
Так почему лимитировать? Предикаты как раз и служат для того, чтобы расширять(до тех пор, пока не начнутся пересечения, на крайний случай, можно модифицировать набор входных паттернов).
Т.е. если у вас вдруг появилась конструкция, которая ранее не встречалась — новый предикат и генератор, проблема решена.
Т.е. если у вас вдруг появилась конструкция, которая ранее не встречалась — новый предикат и генератор, проблема решена.
Написал новую конструкцию за 2 минуты — пишешь предикат — половина тестов сломалась — копаешься полдня — плюешь — пишешь обычную конструкцию.
Именно поэтому я и написал про статический анализатор предметов, чтобы в процессе написания нового видеть возможные пересечения. В конце-концов всегда можно переопределить другой или написать более специфичный предикат
Хм. Не подкопаешься :-)
А как планируете различать Input и Output?
А как планируете различать Input и Output?
А вот это куда более интересно.
Output не используется в рендере, грубо говоря, он ничего не возвращает.
Более того, мы знаем, что самое частое использование аутпута —
this.props.*(someData?)
Т.е., это функция, результат которой не используется в JSXExpressionContainer'е как таковом(не является чайлдом)
Output не используется в рендере, грубо говоря, он ничего не возвращает.
Более того, мы знаем, что самое частое использование аутпута —
this.props.*(someData?)
Т.е., это функция, результат которой не используется в JSXExpressionContainer'е как таковом(не является чайлдом)
Не совсем верно. См.:
Или вы про то, что для событий явно не будет такого?
Возможны ситуации с пробросом обработчиков событий через 2-4 компонента.
И еще один важный момент. В реакте обработчики кастомных событий могут спокойно возвращать какой-то результат (правда хз зачем, но можно). А в ангуляре это невозможно — EventEmitter не даст вам этого сделать.
С другой стороны в некотором реактовском коде можно также встретить передачу функции как параметризацию компонента (что можно перенести напрямую в ангуляровский код). Это пример 2 из этого комментария.
<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.
Проброс — так же весьма интересный вариант. Дело в том, что проброс — это не вызов :) А значит — инпут :)
onChange={e => callExpression}
setName — параметр из props, мы изначально можем сказать, что это функция — Output.
Проброс — так же весьма интересный вариант. Дело в том, что проброс — это не вызов :) А значит — инпут :)
Носите preact или любую другую легковесную реализацию. На реакте свет клином не сошёлся.
Слегка не по теме вопрос — я увидел что вы генерируете типы, и подумал — давно хотелось генерировать рандомные объекты по их ts-интерфейсам и использовать их для упрощения юнит-тестирования, но нет никакой возможности получить доступ к свойствам интерфейсов — на этапе компиляции ts в js типы растворяются. Не знаете ли вы, можно ли использовать один из этапов ts-компиляции для того чтобы схватить список свойств интерфейса?
Вопрос к автору: как успехи с этим проектом? Получилось ли что-то серьезное мигрировать?
Sign up to leave a comment.
Конвертация React в Angular с использованием универсального абстрактного дерева. Proof of Concept