Skip to content
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

refactor: assert moduleExports #132

Closed
wants to merge 1 commit into from

Conversation

rtritto
Copy link
Contributor

@rtritto rtritto commented Dec 15, 2024

No description provided.

@brillout
Copy link
Owner

It's on purpose. I really think we should focus on features instead of internal refactoring :)

@brillout brillout closed this Dec 15, 2024
@brillout
Copy link
Owner

on features

I can share you our list of current priorities if you're interested.

@rtritto
Copy link
Contributor Author

rtritto commented Dec 15, 2024

It's on purpose. I really think we should focus on features instead of internal refactoring :)

During my analysis, I found a minimal and simple refactor. Improve the readibility and the code, should always be accepted.

I can share you our list of current priorities if you're interested.

Sure, I can take a look.

@brillout
Copy link
Owner

It's on purpose. I really think we should focus on features instead of internal refactoring :)

During my analysis, I found a minimal and simple refactor. Improve the readibility and the code, should always be accepted.

These two assert() calls often fail. When this happens I want to know which one of these two fails simply by reading the stack trace, that's why deduping them is actually a regression. As I said before: please trust us with internal stuff 🙂

I can share you our list of current priorities if you're interested.

Sure, I can take a look.

How about one of the following?

WDYT?

@rtritto rtritto deleted the refactor-assert-moduleExports branch December 15, 2024 18:35
@rtritto
Copy link
Contributor Author

rtritto commented Dec 15, 2024

These two assert() calls often fail. When this happens I want to know which one of these two fails simply by reading the stack trace, that's why deduping them is actually a regression.

Good to know 👀

As I said before: please trust us with internal stuff 🙂

Of course. Anyway I/we can't know whether the code is correct or not, so trying (eg with PRs) may lead some positive results. Any help can bring improvements or innovative thoughts; also useful to the community since we are all moving in a common direction.

How about one of the following?

* [New Vike Extensions vikejs/vike#1715](https://github.com/vikejs/vike/issues/1715)

* [New Bati integrations](https://batijs.dev/)

* [Polish handli#6](https://github.com/brillout/handli/issues/6)

* [Automatic UI handling of network issues #103](https://github.com/brillout/telefunc/issues/103)

WDYT?

For the Bati integrations, I created solid-jotai.

For the Jotai integration, a new Vike extension is needed?

The two points of Handli and Telefunc aren't on my scope at the moment.

@brillout
Copy link
Owner

For the Jotai integration, a new Vike extension is needed?

👍 Sounds good, let's give it a try. How about for React i.e. vike-react-jotai?

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

Successfully merging this pull request may close these issues.

2 participants