* Pass preferences up the Fiber tree
* Working preferences (except for backgroundPreferenceValue)
* Initial StateObject support
* Fix layout caching bug
* Support StateObject/EnvironmentObject/custom DynamicProperty
* Add doc comments for bindProperties and updateDynamicProperties
* Use immediate scheduling in static HTML and test renderers
* Add preferences test
* Add state tests and improve testing API
* Attempt to fix tests
* Fix preference tests
* Attempt to fix tests when Dispatch is unavailable
* #if out on os(WASI)
* Add check for WASI to test
* Add check for WASI to TestViewProxy
* #if out of import Dispatch when os == WASI
* Remove all Dispatch code
* Remove address from debugDescription
* Move TestViewProxy to TokamakTestRenderer
* Add memory address to Fiber.debugDescription
* Fix copyright year
* Add several missing types to Core.swift
* Add missing LayoutValueKey to Core.swift
* Fix issues with view trait propagation
* Enable App/SceneStorage in DOMFiberRenderer
* Address review comments
* Revise preference implementation
This PR adds the ability to control `<head>` tags using a new `HTMLTitle` view and `HTMLMeta` view. Taking inspiration from Next.js `<NextHead>`, you can use these views anywhere in your view hierarchy and they will be hoisted to the top `<head>` section of the html.
Use as a view:
```swift
var body: some View {
VStack {
...
HTMLTitle("Hello, Tokamak")
HTMLMeta(charset: "utf-8")
...
}
}
```
Use as a view modifier:
```swift
var body: some View {
VStack {
...
}
.htmlTitle("Hello, Tokamak")
.htmlMeta(charset: "utf-8")
}
```
And the resulting html (no matter where these are used in your view hierarchy):
```html
<html>
<head>
<title>Hello, Tokamak</title>
<meta charset="utf-8">
</head>
<body>
...
</body>
</html>
```
`Toolbar` is new in SwiftUI. It is coupled fairly closely with `NavigationView`, so this should be integrated with that somehow (#130). It was made similar to macOS which allows more than a leading/trailing `ToolbarItem`.
Resolves#316.
Resolves#218.
`String(describing:)` initializer applied to metatypes does not include a module name, which can cause problems if two different types with same name come from different modules.
OTOH `String(reflecting:)` does include module name, which makes these reflection strings slightly longer, but should prevent obscure issues with name collisions from happening.
Adds `_spi(TokamakCore)` to the modules:
1. TokamakCore
2. TokamakDOM
3. TokamakGTK
4. TokamakStaticHTML
The attribute is applied to:
1. All `View` bodies in TokamakCore — either primitive or regular like `Color`
2. `ViewDeferredToRenderer` bodies
4. `ParentView` `children` members
5. `View` modifiers (such as `_onMount(perform:)`)
6. Other members of types (like `Color._withScheme`, and `_AnyApp._launch`)
The attribute semantics (from my brief testing)
1. It can only be applied to `public` declarations
2. It ensures that every SPI declaration is exposed only by other SPI declarations (i.e. `@_spi(Module) public enum A {}; public var a: A` is illegal)
3. Regularly importing a library prohibits clients from accessing SPI declarations that are not protocol witnesses (with an error).
4. Regularly importing a library "discourages" clients from accessing SPI protocol witnesses by hiding them from the autocompletion suggestions (i.e. users can still access `body` of `Text`, but autocompletion hides it).
5. For a declaration marked with `@_spi(Module)`, a client has to write `@_spi(Module) import Library` in order to normally access such SPI declarations.
* Add '_spi(TokamakCore)' to ideally internal public members.
* Remove `_spi` attribute on '_ConditionalContent'.
* Remove spi from 'Path._PathBox', 'Font._Font', and '_TupleScene.body'.
* Remove spi from types.
* Remove trailing whitespace.
* Apply spi to 'View' modifiers.
* Add _spi imports.
* Introduce 'PrimitiveView'.
* Remove 'PrimitiveView' conformances outside of TokamakCore.
* Fix `PrimitiveView` default implementation.
* Remove "BubbleCore" references.
Carson Katri