Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[✨] Receive requestEvent in server$ differently #69

Closed
niconiahi opened this issue Aug 1, 2023 · 1 comment
Closed

[✨] Receive requestEvent in server$ differently #69

niconiahi opened this issue Aug 1, 2023 · 1 comment
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

Comments

@niconiahi
Copy link

niconiahi commented Aug 1, 2023

Is your feature request related to a problem?

today, to access the requestEvent inside a clojure of a server$ 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 how requestEvent is "handed off" from Qwik Router to server$

Describe the solution you'd like

expectation:

import { component$ } from '@builder.io/qwik';
import { server$, routeLoader$ } from '@builder.io/qwik/qwik-city';
 
const encryptInServer = server$(({ env }: RequestEvent) => (message: string, luckyNumber: number) => {
  const secretKey = env.get('SECRET_KEY');
  const encryptedMessage = encrypt(message, secretKey);
  console.log('the lucky number is =>', luckyNumber)
  return encryptedMessage;
});
 
export default component$(() => {
  return (
    <>
      <button
        onClick$={() => {
          const encrypted = await encryptInServer('Hello world', 22);
          console.log(encrypted);
        }}
      >
        Click me
      </button>
    </>
  );
});

as you control server$, I think it should be possible to take the parameters' values when executing encryptInServer (in the onClick$) and provide them in the server$ as arguments but in a different way than today

Screenshot 2023-07-31 at 21 42 43

Describe alternatives you've considered

I didn't consider any other alternative, to be honest

Additional context

No response

@gioboa
Copy link
Member

gioboa commented Oct 14, 2024

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.

@gioboa gioboa transferred this issue from QwikDev/qwik Oct 14, 2024
@github-project-automation github-project-automation bot moved this to In Progress (STAGE 2) in Qwik Evolution Oct 14, 2024
@github-actions github-actions bot added [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 labels Oct 14, 2024
@QwikDev QwikDev locked and limited conversation to collaborators Oct 14, 2024
@gioboa gioboa converted this issue into discussion #140 Oct 14, 2024
@github-project-automation github-project-automation bot moved this from In Progress (STAGE 2) to Released as Stable (STAGE 5) in Qwik Evolution Oct 14, 2024
@shairez shairez removed this from Qwik Evolution Oct 15, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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
Projects
None yet
Development

No branches or pull requests

2 participants