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
New event handling #1240
New event handling #1240
Conversation
3a1c4ec
to
941245b
Compare
const isCallable = pyCallable(evalResult) | ||
|
||
if (isCallable) { | ||
const pyInspectModule = interpreter.interface.pyimport('inspect') |
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.
@antocuni this is what I need the interface
for
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.
if I understand it correctly, here you are trying to detect whether the user provided something which is not a callable to show a better error message, aren't you?
If so, I propose the following plan:
-
for now, you should be able to fix it using
interpreter._remote.interface
. But note that when you use theRemoteInterpreter
everything is async, so I suspect you will have to putawait
in front of every line. This should at least be able to unblock you -
for later, we might want to move this logic directly to
RemoteInterpreter
: e.g.,RemoteInterpreter
could have a method calledisPyCallable()
which checks whether the given name is actually a callable, and a corresponding method onInterpreterClient
. But I don't really understand why you need to inject theevt
argument so I want to understand it more
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.
it worked without await 💃
e1158fc
to
6a20bbe
Compare
92e8d1d
to
b648c58
Compare
For what it's worth, |
Yeah let's kill those 😄 |
for more information, see https://pre-commit.ci
5a90898
to
f2fc1ae
Compare
'volumechange', | ||
'waiting', | ||
'toggle', | ||
); | ||
|
||
/** Initialize all elements with py-* handlers attributes */ | ||
export async function initHandlers(interpreter: InterpreterClient) { |
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.
I don't personally care about other linters errors but this one in particular seems to be reasonable ... why is this callback async
if there's not a single await
in it?
Let's remember that if consumer code does await initHandlers(...)
works regardless the callback is a Promise (async) or not, so this async
feels a bit off to me ... what do you think? 🤔
e19ce0a
to
701681b
Compare
Ok so, as of last week I've joined this code to the one in the main after @madhur-tandon and @hoodmane's efforts on converting everything to Currently the first three tests are passing, these tests are independent of the JS side, here's an example of one of them, you can look at the rest in the file def test_decorator_click_event(self):
self.pyscript_run(
"""
<button id="foo_id">foo_button</button>
<py-script>
from pyscript import when
@when("click", id="foo_id")
def foo(evt):
print(f"I've clicked {evt.target} with id {evt.target.id}")
</py-script>
"""
)
self.page.locator("text=foo_button").click()
console_text = self.console.all.lines
assert "I've clicked [object HTMLButtonElement] with id foo_id" in console_text Ok so this makes it very clear that the problem is happening in the JS side. Specifically in the function I've changed here in this PR Insights here are +++ |
Have been doing some investigation on this this afternoon, and have a mostly-working fork of this PR. 8 of 9 tests pass. Working on cleaning it up in a way that makes it mergeable to this PR. The one that fails is For the time being, we might have to either get more tricky with how we identify instance methods or, what I'd suggest to get this merged, is just say the instance methods don't work yet and do it as a separate PR. 😅 |
Update - the fork is at jeffersglass/events-demo-jg-contrib. There's only two extra commits on top of this PR - the first is just merging from |
Nice! I'm with you it would be nice to get this in before PyCon since events are very weird to work with at the moment |
I was unable to reproduce either of these issues... Maybe I am not understanding something correctly. |
Turned out to not be a purely Pyodide issue as I thought/put in that Issue, sorry about that. But it does still seem to be an issue with something we're doing here. The simplest way to see it (and I will try to get a minimal example together as well) is:
Inside the <py-script> tag of that test, you can add the following, which shows the bound method as having 1 parameter: import inspect
print(f"{len(inspect.signature(instance.someEventFunc).parameters)= }") But In pyscript.ts line 195, you can add a It's surely possible I'm misunderstanding something about how Synclink/Pyodide is proxying things here... |
Hmmmm no it seems either I'm wrong again or I'm misunderstanding how we're using Synclink in PyScript. I set up a minimal synclink+pyodide example, and in that instance it seems inspect.signature has no problem identifying the number of parameters:
So, probably not an upstream bug an all, but something I'm not understanding about our new setup. On the other hand, I've learned quite a bit about Synclink in the last day, which is nice. |
Just to confirm, Jeff are you blocked by that bug you reported? This PR has been open for a while and I think we should improve event handling 😄 |
@FabioRosado Not blocked, just need to find the time to actually identify what's wrong in the current code and make the fix. I haven't had much time to spare on it in that past week, with PyConUS and all. But agreed - would love to have this in! With circumstances being what they are, I will probably end up closing this PR and opening a fresh one on a branch I can push to. Perhaps I'll do that now. |
Sounds good didn't want to rush just wanted to check if you wanted me to try and take it over although I am completely out of the loop with all the awesome work 😄 Yeah that's probably a good idea |
Hello folks 👋 With the landing of #1403 this discussion looks like a piece of cake to me ... beside the MutationObserver story which is something easier to implement now, but I think it should be a PR a part after this is solved/fixed/landed. To me the little changes to apply to current code is:
If my understanding is right, and since nobody is assigned to this issue, I'd be more than happy to address this part and improve the recently already improved logic, covering 80% of the proposal goal. Thoughts? |
Just to be sure, does that mean the whole work with the This is just an opinion, but if the use case of |
right, admittedly I wrote my comment before reading (or understanding) the current PR or considering the as it looks like I need way more background before jumping on this issue or try to solve it, I am keen to make a step back at least until I fully understand the whole story. Apologies for the rushed comment, happy to answer any question around current simplified events dance ... the most important thing is that we can literally check any |
Hi y'all - currently working on breaking out the Will have that shortly, and once it's up, I think we should close this PR and break out a fresh one for the changes to the HTML-attribute-based event handling. @WebReflection you may have found it already, but that syntax is described in #1222. |
To move this forward, and since #1403 introduced quite a few merge conflicts/improvements to main, I'm going to close this PR in favor of two new ones:
Some really excellent work and discussion were had here, and I don't want to discount or lose any of that. Mostly making the split for logistical reasons and to allow us to get the great parts of this PR merged into main soon. 😁 |
Collaboration from @FabioRosado @JeffersGlass @mchilvers and I on events :)
A bit messy, will start cleaning it up and adhering to what's being discussed here. Thanks all!