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

Там такие трудности что дай боже. Именно поэтому до сих пор нету хот релоадинга в native приложениях. Есть хаки с динамической перегрузкой библиотек, но это не hot patching

у меня будет уклон в сторону stateless функций-компонентов-шаблонов и некой базы данных на клиенте (где будет храниться состояние всех компонентов), первое будет хот-релоадится а для второго напишу механизм миграций

А база где?

блин, сюда кто-то кидал статью с хабра про миграцию плюсов ого проекта на васм и чот я ссылку не могу найти

кто-нибудь может повторить？

тоже в AS, в отдельном куске памяти (новому модулю известно предыдущий шейп и он берет и конвертирует эти объекты предыдущего шейпа в новый шейп в отельный кусок памяти и дальше свапим, по сути это примерно то как sql-базы данных делают миграцию когда добавляешь колонку - они создают новые шейпы/таблицу в отдельном куске памяти а потом копируют текущие поля и в конце удаляют старые инстансы объектов)

@maxgraey я правильно понимаю что AS пока не поддерживает объектные литералы с разным набором полей (автоматическое создание скрытых классов и попытка получить в рантайме инфу о наборе полей для свитч-обработки) и опциональных полей тоже нет ?

Я тут думаю над тем как представлять шаблоны компонентов средствами AS (без дополнительной компиляции). В реакте есть jsx где html по сути компилируется в вызов React.createElement() и такой шаблон

const SomeComponent = () => {
  return <div style={{
      width: 100,
      height: 200,
      backgoundColor: "blue"
  }}>
     <div style={{....}}></div>
     <div style={{....}}></div>
     <AnotherComponent prop1={..} prop2={}/>
  </div>
}

const AnotherComponent = () => {
  return <div style={marginTop: 10, ...}>
    ...
  </div>
}

эквивалентен такому дереву вызова функций

//хелперы
const Div = (style, children) =>  React.createElement("div", {style}, children);
const component = (Component) => (props) => React.creatElement(Component, props) 

//компоненты
const SomeComponent = component(() => {
  return Div({
      width: 100,
      height: 200,
      backgoundColor: "blue"
     }, [
       Div({...})
       Div({...})
       AnotherComponent({prop1: ..., prop2: ...})
     ]})
})

const AnotherComponent = component(() => {
  return Div({style: marginTop: 10 }, [
    ...
  ])
})

И я уже довольно давно пишу на реакте таким образом (вместо транспиляции jsx вызываю React.createElement напрямую в атомарных компонентах).

Я правильно понимаю что в AssemblyScript не выразим подобный паттерн императивного построения структуры объектов с разным наобором полей (например в одном случае мы передаем width, height, в другом только paddingTop в третьем margin + justifyContent) ?

const SomeComponent = () => {
  return Frame({
   width: 500,
   height: 500
   children: [
     Frame({
       paddingTop: 10,
       children: [
         Frame({
           marginLeft: 10,
           justifyContent: "center"
           children: [...]
         })
       ]
     })
   ]
 })
}

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

const SomeComponent = () => {
  return Div().width(500).height(500).child(
    Div().paddingTop(10).child(
      Div().marginLeft(10).justifyContent("center")
    ).child(
      ...
    )
  ).child(
    ...
  )
)

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

Посмотри в репозитарий что я тебе скинул.

Ну все равно AOT нужен

JSX натравить на кодоген типов не так сложно

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

// без коструктора
class Point {
   x: i32
   y: i32
}

function foo(pt: Point): void {
}

foo({ x: 1, y: 2 }) // то так можно

Для своего JSX или другого DSL придеться делать препроцессинг. В AS есть хуки в transform (смотри документацию)

Но как быть с разным набором полей? Опциональные поля в AS пока не поддерживаются? По сути основное требование ui-фреймворков в том чтобы описывать интерфейс деревом базовых кирпичиков которые могут иметь кучу пропсов-стилей но передаем мы только нужные (а остальные имеют дефолтные значения)

```
class Point {
  x: i32
  y: i32
      z:  i32 = 0
}
```

вот опциональное поле (имеет дефолтное значение)

ок, буду пробовать, спасибо)

забавно, опциональные поля работают (билдится успешно) но ругается тайпскрипт что не хватает поля (скриншот из webassembly.studio), а если пометить знаком вопроса то у тайпскрипта ошибка пропадает но теперь ругается AS - "ERROR AS219: Optional properties are not supported."

optional != default initilased