Skip to content

Reactive conditions #3

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

Open
kethan opened this issue Jul 17, 2022 · 6 comments
Open

Reactive conditions #3

kethan opened this issue Jul 17, 2022 · 6 comments

Comments

@kethan
Copy link

kethan commented Jul 17, 2022

Hi, very nice library.

How do I under such conditions in the counter example?

{count.value % 2 === 0 ? <div>Even</div>: <div>Odd</div>}
@kethan
Copy link
Author

kethan commented Jul 24, 2022

@wlib

@wlib
Copy link
Contributor

wlib commented Jul 24, 2022

Sorry about the late reply Kethan. Bruh is a bit unlike react in some ways; that count.value access would only run once (because it just gets the current value of count). To get the desired behavior, the "Odd"/"Even" should be a reactive value itself.

const parity = r([count], () =>
  count.value % 2 === 0
    ? "Even"
    : "Odd"
)

return <div>{ parity }</div>

@kethan
Copy link
Author

kethan commented Jul 24, 2022

Oh wow that's so simple. Before I tried with https://github.com/kethan/ulive instead of your reactivity it works like charm.

@kethan
Copy link
Author

kethan commented Jul 24, 2022

@wlib is there a way I can implement a clean up function when component exits like i want to remove event listeners, etc ??

@wlib
Copy link
Contributor

wlib commented Jul 24, 2022

I'm not quite sure how to answer that because there is no component lifecycle, so there is no component unmounting. This may change in the future, but I'm trying to keep it as close to "standard html/js" as I can for future-proofing. The trouble with lifecycle methods is that they would force bruh to constrain how you use elements a little too much, as bruh's elements are nothing more than plain elements created with document.createElement(). It's too difficult to tell when an element is really "done" automatically because you could always just take an element out of the DOM and place it somewhere else any time later.

The HTML standard has moved towards AbortSignal for some things like fetch() cancellation and custom cancellation. It's neat because one signal can be used for everything that should be affected, as shown here for multiple fetches and here for multiple event listeners.

If you could show me your exact use case I might be able to show you how I would do it. If I don't have a good solution right now, then it's something I will definitely need to think about how to add support for.

@kethan
Copy link
Author

kethan commented Sep 12, 2022

Yes you right. But i do have an usecase i will try to share with you. It's just like solidjs oncleanup function it just cleans up old effects when run new effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants