* Add a test for environment injection
We had some issues in this code area previously and I'm thinking of refactoring it in attempt to fix#367. Would be great to increase the test coverage here before further refactoring.
* Update copyright years in `MountedElement.swift`
* Update copyright years in the rest of the files
Resolves, but adds no tests cases to the test suite for #294. See the issue for the detailed description of the problem.
I will add end-to-end tests for this in future PRs.
I've tested these cases manually so far:
```swift
struct Choice: View {
@State private var choice = false
var body: some View {
HStack {
Button("Trigger") {
choice.toggle()
}
if choice {
Group {
Text("true")
Text("true")
}
} else {
VStack {
Text("false")
}
}
Text("end")
}
}
}
```
Note the `Group` view with multiple children in this one, it uncovered required checks for `GroupView` conformance.
Also tested these more simple cases:
```swift
struct Choice: View {
@State private var choice = false
var body: some View {
HStack {
Button("Trigger") {
choice.toggle()
}
if choice {
Group {
// single child
Text("true")
}
} else {
VStack {
Text("false")
}
}
Text("end")
}
}
}
```
and
```swift
struct Choice: View {
@State private var choice = false
var body: some View {
HStack {
Button("Trigger") {
choice.toggle()
}
if choice {
// single child, no nesting
Text("true")
} else {
VStack {
Text("false")
}
}
Text("end")
}
}
}
```
This PR requires `carton` 0.6.0 that you can install from Homebrew as usual.
To cleanly manage scheduler closures, new `JSScheduler` class is introduced that conforms to OpenCombine's `Scheduler` protocol. I think it will be moved to OpenCombineJS in the future.
* Fix compatibility with JavaScriptKit 0.7
* Formatting update
* Specify `carton` 0.6.0 as a requirement
* Optimize immediate schedule function
* Update formatting
Resolves partially #231. `_targetRef` is a modifier that can be used by any renderer, while `_domRef` is an adaptation of that for `DOMRenderer`. Both are underscored as they are not available in SwiftUI, and also their stability is currently not so well known to us, we may consider changing this API in the future.
Example use:
```swift
struct DOMRefDemo: View {
@State var button: JSObjectRef?
var body: some View {
Button("Click me") {
button?.innerHTML = "This text was set directly through a DOM reference"
}._domRef($button)
}
}
```
I've also fixed all known line length warnings in this PR.
You can see the dark scheme environment text representation updated in `EnvironmentDemo`. I suggest adding default dark mode styles in a separate PR, I've created #237 as a reminder for that.
Removes the `View`-based initializer of `DOMRenderer` which no longer leaves any `public` initializers on it, means we can make it fully internal. `DOMNode` is now internal too, which is great as it was an implementation detail anyway. Corollary, `DefaultApp` is no longer needed.
`Target` was cleaned up is it doesn't need to hold `App` or `Scene` values, now it's just a simple protocol.
I've updated `README.md` to show usage of the `App` protocol in the basic example.
Closes#224.
This based off the `buttonstyles` branch by @Outcue.
Initially it didn't work because mounted host views didn't propagate their environment on updates. This is now fixed by adding `updateEnvironment` function on `MountedElement` base class and calling it in the initializer. Manual environment updates are no longer needed in `makeMounted...` factory functions. `makeMountedApp` is no longer needed at all and `MountedApp` initializer can be used directly then.
This means that the `View` initializer of `DOMRenderer` now can delegate to the `App` initializer by creating a wrapping `DefaultApp`. It would simplify https://github.com/swiftwasm/Tokamak/pull/136 for me, where I no longer need to implement color scheme observation for these two different codepaths separately.
We currently have the reconciler code duplicated in these types. I also have a draft `MountedScene` implementation, which most probably would rely on the same reconcilliation algorithm. In this PR it's made generic and can be shared across these types of mounted elements.
1. If a Stack has a Spacer as a child, we need to fill the width or height of the parent so the Spacer's flex-grow: 1; works.
2. If a Stack has a child Stack along the cross axis (HStack with a nested VStack and vice vera) we need to fill the cross axis
3. If a Stack has a child Stack along the same axis (HStack with a nested HStack) we need to fill the axis.
Max Desiatov