This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
[✨] Receive requestEvent
in server$
differently
#69
Labels
[STAGE-2] incomplete implementation
Remove this label when implementation is complete
[STAGE-2] not fully covered by tests yet
Remove this label when tests are verified to cover the implementation
[STAGE-2] unresolved discussions left
Remove this label when all critical discussions are resolved on the issue
[STAGE-3] docs changes not added yet
Remove this label when the necessary documentation for the feature / change is added
[STAGE-3] missing 2 reviews for RFC PRs
Remove this label when at least 2 core team members reviewed and approved the RFC implementation
Is your feature request related to a problem?
today, to access the
requestEvent
inside a clojure of aserver$
primitive, you have to use the this keyword. I personally don't like using this like that, feels so imperative. Where is it coming from? feels extra magical. I would prefer seeing it coming a parameter as all the other primitives do. That way does feel really natural, because of the reactive (and functional IMO) nature of Qwik. The this really feels like classes. So because of that I've thought that maybe it would be interesting to change howrequestEvent
is "handed off" from Qwik Router toserver$
Describe the solution you'd like
expectation:
as you control
server$
, I think it should be possible to take the parameters' values when executingencryptInServer
(in theonClick$
) and provide them in theserver$
as arguments but in a different way than todayDescribe alternatives you've considered
I didn't consider any other alternative, to be honest
Additional context
No response
The text was updated successfully, but these errors were encountered: