QwikDev
[DOCS] Make the React/Qwik cheat sheet a little more tailored to react devs coming to qwik
How can the documentation be improved?
This is regarding the qwik/react cheatsheet here: https://qwik.builder.io/docs/cheat/qwik-react/
- In the examples, list
From "React"header first, thenTo "Qwik"after that. It's confusing to someone coming from React that the Qwik code examples are listed before the React ones. Listing the "from" first will provide recognizable context to transition from. - Add descriptive sentences below each header, explaining what to pay attention to.
- After showing the example, provide some minimized Q/A that can be clicked on to explain the "why"
- Don't forget to list things which are the same. For example, not everything should be wrapped in
component$. Simple inline components probably shouldn't, which works just like React. - In React, it is recommended to use
useCallbackfor event handlers to ensure your functions are immutable so that you don't trigger re-renders all the time. It's also a better practice to try and keep your jsx readable by separating the events out. The docs inline a button click event handler. If you try to move the function out of the JSX in Qwik, this can get really weird with Qrls and such. Update the button example to show both inline function calls anduseCallback-style functions outside the JSX.
To illustrate a few things, the example below shows some better header ordering, some descriptive text, and Q/A afterwards to explain "what happened" (answer the "why am i doing this differently?")
Rendering an inline component
Sometimes we construct simple components which should be inlined within any component. Styled Components and Emotion both encourage patterns like this. Rendering simple inline components in either React or Qwik are the same.
From React
export const Foo = () => <div className={styles.foo} />;
To Qwik
export const Foo = () => <div className={styles.foo} />;
Rendering an average component
Regular components however should be identifiable so that they can be optimized. We wrap these in component$ wrappers:
From React
export const DatePicker = () => {
// ...much logic
return <div>Date picker here</div>;
};
To Qwik
export const DatePicker = component$(() => {
// ...much logic
return <div>Date picker here</div>;
});
What happens when I wrap my component with `component$`?
Answer: The optimizer identifies this as a split point in your bundle, allowing it to be isolated from other scripts in your app to be loaded only when needed. Read more about optimization details here.
Inline components are not the same as inline component in React. Using an inline component is like calling the function directly (and can't use hook inside).
True for inline handlers vs passing a function reference to the event prop. However useCallback is used purely for optimization (and should not be used until you have performance bottlenecks) in React and showing this in the React would be adding complexity for nothing.
@ChibiBlasphem I wasn't sure on the best wording. My point was less about the specific case, and more about listing out what "still works like you'd expect", but also "where to think differently and why".
Specifically regarding that point though, I am not sure it's a good practice to wrap every tiny little component in component$, though I could be wrong. Originally where $component added host element wrappers, that would have led to DOM bloat. But with host elements gone, maybe the overhead is less. It would be good to provide options if there should be options, with clear reasoning why.
can this become a PR? i would love to merge any improvement to this section!
Hi @dzearing if you want we can work together on the PR, in principle I understand that we would have to reverse the order "from react" / "to qwik". What is not clear to me like you is the inline components and always create a component with component$ (although I understand that it would be the right thing for the optimizer to create the corresponding chunk).
@manucorporat Could you enlighten us a little on this? Thanks 😊
Could I contribute?
I am working on this issue on this PR https://github.com/BuilderIO/qwik/pull/4976 it is still work in progress, so if you want to contribute, you are welcome to do so @sdkdeepa ♥️
Taking into account the issue comment I did something like this (I also corrected some errors in the tests, as I tested each one locally 😅):
