-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add @EnvironmentObject #170
Conversation
Generated by 🚫 Danger Swift against ba17ce2 |
func subscribe(_ closure: @escaping () -> ()) | ||
} | ||
|
||
@propertyWrapper public struct EnvironmentObject<ObjectType>: EnvironmentReader, EnvironmentWriter where ObjectType: ObservableObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 🚫 Line should be 100 characters or less: currently 135 characters (
line_length
)
Hm, I was thinking of building |
Also, |
In SwiftUI |
Sorry, I mean on top of |
I see that you tried to merge that PR in your fork, you may find this issue somewhat useful with regards to compiling C++ dependencies swiftwasm/swift#595 (comment) |
So I would need to pass those flags to the linker for it to compile the cpp? Or it’s just not in a working state? |
Most probably still not in a working state, unless it was fixed in LLVM in the meantime, need to have another look to clarify |
Ok, because I tried to build and it failed while building |
I'll investigate it after I have #167 resolved, unless you'd like to start working on it now yourself. |
I can try but I’m not sure where I’d start 🤔 |
I got the includes to resolve by adding the c++/v1 as an include directory, but their #include_next couldn’t be found. |
This is probably related to issues like WebAssembly/wasi-sdk#93, but that one was created just for a single header, while I think there are multiple headers like that. If we can make sure that the runtime bits of that OpenCombine PR compile with the standard WASI SDK, we can make similar (or same) adjustments in our SwiftWasm build and then reproduce successful builds with SwiftPM. This is the line that triggers the LLVM headers install rule, so it would probably involve compiling WASI SDK from scratch with changes applied to appropriate CMake files in LLVM/Clang. Just want to prepare you that working on the SwiftWasm and LLVM/Clang toolchains is a tedious process that requires a ton of disk space (dozens of gigs) and very preferably the most powerful hardware you can get to compile it in reasonable time. There is the LLVM "Getting Started" guide and the upstream "Development tips" doc that I highly recommend to check out. I would probably start it with creating a new I haven't looked into it deeply enough, but it's quite possible you'll have to compile your own WASI SDK and then integrate that into our builds. We have our own fork repository for that, but it's slighly outdated, which could cause some problems too 😔 That's basically the intro to the toolchain development in my own words, I'm sure I unintentionally missed some parts, but I don't know what's your experience with the custom toolchain builds. Please let me know if you stumble upon any problems, and it's totally fine to abandon this to focus on other more interesting tasks in the meantime 🙂 |
Another totally hacky solution I'd like to try is to modify the headers locally so that it compiles, then either cobbling together an installable SDK from that manually or injecting fixed headers into the toolchain build script. After that works we can look into the LLVM/Clang headers build steps in more details. |
I think I've got it built, haven't verified if it works yet though. Required a couple of changes in both OpenCombine and WASI sysroot, PRs incoming... |
This is a first attempt, still not hooked in the reconciler and requires a custom toolchain.
Do you consider using CombineX which support |
Sorry, I don't think so. OpenCombine supports |
Yes, I was carefully not suggesting CombineX as you, as the library author, are co-maintainer of OpenCombine (and I'm co-maintainer of CombineX). But I see many technical disadvantages of OpenCombine:
Anyway, you're the owner and it's all up to you. (And nothing stops you from being a co-maintainer of CombineX) EDIT: So OpenCombine now supports |
Sure, thank you for the suggestions. I'd have to disagree on those points though, except maybe the use of OpenCombine on macOS 10.15 (which I hope we can fix in the near future). There's no requirement for custom compiler flags whatsoever, and as I mentioned above, |
What changes did you have to make to the toolchain for it to work? (any relevant commits?) |
Sorry, no commits yet, but I think you'll be able to reproduce it if you swap It only removes unsupported headers like I hope to submit a PR that integrates this change in the toolchain builds ASAP. |
@ddddxxx sorry if my response sounded confrontational, I wish I phrased it in a better way. I hope we all can collaborate and improve the ecosystem together without duplicating our work. I'm not sure if there's an easy way out of this unless either OpenCombine or CombineX decide to merge their code into another one, or maybe we could create a separate new project to join our efforts, and I'm not the person to make that decision. Anyway, I think this is offtopic and not very related to Tokamak itself, so I hope we can continue this discussion, if you'd like to, in a more suitable setting outside of Tokamak project issues. |
@MaxDesiatov It's not confrontational. I'm also curious how do you fix OpenCombine on macOS 10.15, in OpenCombine or Carton? Because I faced the same problem. Should we create an issue in OpenCombine or Carton? [off-topic] I feel the division of the community and ecosystem is inevitable. even I did my best to make CX and my libraries also support OpenCombine. Now I hope Apple open source their Combine and solve this once for all. |
Update WASI SDK to fix C++ setjmp/signal headers Fixes the issue #595 with C++ packages for the development snapshots made from the `swiftwasm` branch. Previously C++ dependencies couldn't be built as default Clang headers weren't tailored to support WASI, WebAssembly/wasi-sdk#93 being one of the examples. This should also unblock TokamakUI/Tokamak#170.
func subscribe(_ closure: @escaping () -> ()) | ||
} | ||
|
||
@propertyWrapper public struct EnvironmentObject<ObjectType>: EnvironmentReader, EnvironmentWriter where ObjectType: ObservableObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 🚫 Line should be 100 characters or less: currently 135 characters (
line_length
)
Generated by 🚫 Danger Swift against 5f8f02e |
I believe the Environment injection issues are resolved. Also EnvironmentObject is implemented 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works great when merged into my navigation
branch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome 🙌
Currently changing the environment object doesn't redraw. What do you think the best way of triggering that would be @MaxDesiatov?