-
Notifications
You must be signed in to change notification settings - Fork 5
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
Post-merge issues of decoupling the interface #203
Comments
I really wish I merged that big change into a dev branch, shouldn't code when falling asleep 😄 I needed a solid version, with the #200 change, so here what I did today:
So we now have We still have that You mentioned that the split of sync and async will require the same for custom operators... I wonder how this will look. I've run into a library shortcoming with the injectors, where I have to use |
I've updated dev to have the new changes.
|
Just tried it,
|
Does 2.7.0 show up when you run |
Try |
That did it,...will release the direct commit hook now, and try again :) |
With regard to the documentation, there seems to be a bunch of "references" for types that are exported by multiple namespaces. It seems the One simple solution could be just to only export those types in the |
Branch re-basement finished, looks good, cheers! |
This code should work in with
Note: If you are using TypeScript, you'll need to set |
So how is it going to work inside web browsers? 2.7.0 works perfectly in my Angular projects, but 2.7.0-beta.0 cannot resolve the path... And I cannot change the module target there, because changing it breaks everything else. |
In what regard? web browsers don't need type information. |
Angular, for example sets |
Also, if the library requires tweaking |
So AngularJS support has officially ended as of January 2022 so AngularJS might not ever support In this case, you'd need to do things to other (older) way. import { async } from "iter-ops";
const { pipe, map } = async;
const input = [1, 2, 3];
const output = pipe(
input,
map((x) => Promise.resolve(x * 2))
);
(async () => {
for await (const o of output) {
console.log(await o); // This extra await shouldn't be needed. Bug?
}
})(); Edit: Just realized that Angular and AngularJS are different. 👅 |
I wasn't talking about the ancient AngularJS, but the modern Angular v15, which is a totally different thing these days :) b.t.w. That's my primary tool for Web. I'm an Angular specialist ;) |
So that code example in my previous comment should work for you for now until that linked issue is resolved. |
I just redid my tests against the very latest Angular, and it behaves differently again... Now setting And for some reasons it wants to find things inside |
Here's the way it should be able to be imported: Option 0 - No changes:
import { pipe, delay, tap } from "iter-ops"; Option 1 - Classic resolution to access the new namespaces:
import { async } from "iter-ops";
const { pipe, delay, tap } = async; Option 2 - Modern resolution to access the new namespaces:
import { pipe, delay, tap } from "iter-ops/async"; Option 3 - Access the internals to access the new namespaces:
import { pipe, delay, tap } from "iter-ops/dist/async"; |
I'm not sure how we are going to proceed here, I'm just gonna leave it in your hands, for now. Version 2.7.0 installs and works without any issues everywhere, and we should have the same expectation for this branch, which is currently not the case, as far as I can see it... For the time being, I might just focus on something simpler... like picking some operator from custom operators, and adding it to the library. Operators like P.S. We clicked submit almost at the same time 😄 it's not an answer to your last post) |
Per your comments earlier + mine after, is there an option that would make it work reliably out of the box in both NodeJS (v12+) and Web without any post-install changes? That really would be the priority. |
You should be able to use the library exactly the same way as you could before. import { pipe, delay, tap } from "iter-ops"; The new changes are an optional alternative way to do things. |
I just updated the tests and fixed up a few bugs that were revealed when doing so. |
What are the breaking changes? Trying to figure out if 2.8.0-beta.0 would be more appropriate... |
They are very minor ones. I might even be able to remove them and make it so there aren't any. The type Other than that, there may not actually be any. The other major changes I made don't actually seem to be publicly visible. |
|
I took some time going over the I honestly do see this as an improvement. It might offer better type casting (I'm guessing here), but it replaces the plain I like the current architecture, it is way simpler, the way I see it. And I most definitely wouldn't want to complicate the idea of simple custom operators, with one where you have to create 4 files for it... that's just gonna be a turn-off for most developers, IMO. I really do not want to seem ungrateful for how much code you have written for it, it is an incredible job, but I'm not sure I want this change. I wish we discussed it first, or you just did a POC instead... Really sorry! |
I've made some changes to the dev branch to restructure things and simplify it a bit. I think I might have also been able to solve the resolution issue so that There are some type issues that have arisen from the rebase, it should be an easy fix. Let me know what you think of this change. |
I have postponed this for now, and released v3.0.0 without it, for there were too many changes since v2.0.0 as it is. Also, we need a solid milestone here before considering such a big change as decoupling the interface. |
I believe I've now fixed up all the issues. |
Published In the meantime, check out TC39 update. |
This is to address issues after PR #202, as a major rework of the architecture.
@RebeccaStevens Let's address any and all issues of that merge here, rather than the PR itself.
The text was updated successfully, but these errors were encountered: