Bump deps

Make sure all preacts are the same

Retools useSetup

This commit introduces a way to use useSetup with the setup/compute pattern.

I intend for this to be the default way to introduce React users to Starbeam in the future. This will be coupled with documentation about the importance of the setup/compute pattern to Starbeam and a way to package up universal reactive objects that use the pattern.

Fix the demos (which were still using Component)

Introduce Custom/CustomBlueprint

The idea is to introduce a packaged up concept that useSetup can use directly. This clarifies the setup/compute model for basic reactive objects, and makes it possible to package up custom reactive objects that renderers can use directly.

TL;DR this is the start of clarifying and implementing a pattern for writing universal reactive code in a similar manner as we currently support writing universal resources.

My hope is that resources become a souped up version of Custom, and that the explanation for universality flows neatly from Custom to Resource to Service/Modifier.

🤞

Tweak API

This commit introduces a way to use useSetup with the setup/compute pattern.

I intend for this to be the default way to introduce React users to Starbeam in the future. This will be coupled with documentation about the importance of the setup/compute pattern to Starbeam and a way to package up universal reactive objects that use the pattern.

Bump deps

Make sure all preacts are the same

Retools useSetup

This commit introduces a way to use useSetup with the setup/compute pattern.

I intend for this to be the default way to introduce React users to Starbeam in the future. This will be coupled with documentation about the importance of the setup/compute pattern to Starbeam and a way to package up universal reactive objects that use the pattern.

Fix the demos (which were still using Component)

Introduce Custom/CustomBlueprint

The idea is to introduce a packaged up concept that useSetup can use directly. This clarifies the setup/compute model for basic reactive objects, and makes it possible to package up custom reactive objects that renderers can use directly.

TL;DR this is the start of clarifying and implementing a pattern for writing universal reactive code in a similar manner as we currently support writing universal resources.

My hope is that resources become a souped up version of Custom, and that the explanation for universality flows neatly from Custom to Resource to Service/Modifier.

🤞

Tweak API

What's the deal with this?

Although TS 5.0 also supports ES decorators, we will not add decorators transform to the preset-typescript like we did for other stage 3 features. Use the following config if you want to try ES decorators and TS 5.0 features:

{
  "presets": ["@babel/preset-typescript"],
  "plugins": [["@babel/plugin-proposal-decorators", { "version": "2022-03" }]]
}

What's the rationale?

Now that this feature is in TypeScript 4.9, it's even more glaring that this still doesn't work.

WIP

Introduce Custom/CustomBlueprint

The idea is to introduce a packaged up concept that useSetup can use directly. This clarifies the setup/compute model for basic reactive objects, and makes it possible to package up custom reactive objects that renderers can use directly.

TL;DR this is the start of clarifying and implementing a pattern for writing universal reactive code in a similar manner as we currently support writing universal resources.

My hope is that resources become a souped up version of Custom, and that the explanation for universality flows neatly from Custom to Resource to Service/Modifier.

🤞

Is there a reason not to implement a similar keyword for public readonly properties which would do the same, but without a setter?

More generally, is there a reason that readonly accessor isn't supported?

Fix the demos (which were still using Component)

Bump deps

Make sure all preacts are the same

Fix lints (and don't run lints on the root)

This lint was a false positive

Disabling it caused type errors elsewhere.

We may want to disable prefer-return-this-type, but that's a topic for another PR.

Merge branch 'main' into feature/react-use-setup-2.0

Bump deps

Make sure all preacts are the same

Fix lints (and don't run lints on the root)

This lint was a false positive

Disabling it caused type errors elsewhere.

We may want to disable prefer-return-this-type, but that's a topic for another PR.

This lint was a false positive

Disabling it caused type errors elsewhere.

We may want to disable prefer-return-this-type, but that's a topic for another PR.

Fix lints (and don't run lints on the root)

This commit introduces a way to use useSetup with the setup/compute pattern.

I intend for this to be the default way to introduce React users to Starbeam in the future. This will be coupled with documentation about the importance of the setup/compute pattern to Starbeam and a way to package up universal reactive objects that use the pattern.

Make sure all preacts are the same