create-qwik 0.0.31 → 0.0.34-dev20220701233003

package/starters/apps/qwik-city/src/components/page/page.tsx

@@ -1,24 +0,0 @@
-import { component$ } from '@builder.io/qwik';
-import { useHeadMeta, usePage } from '@builder.io/qwik-city';
-import NotFound from '../../layouts/not-found/not-found';
-
-export const Page = component$(() => {
-  const page = usePage();
-  if (page) {
-    const attrs = page.attributes;
-    const Layout = page.layout;
-    const Content = page.content;
-
-    useHeadMeta({
-      title: attrs.title + ' - Qwik',
-      description: attrs.description,
-    });
-
-    return (
-      <Layout>
-        <Content />
-      </Layout>
-    );
-  }
-  return <NotFound />;
-});

package/starters/apps/qwik-city/src/components/sidebar/sidebar.css

@@ -1,12 +0,0 @@
-aside {
-  padding: 10px;
-}
-
-.menu h5 {
-  font-size: 18px;
-  font-weight: 800;
-}
-
-.menu li a {
-  text-decoration: underline;
-}

package/starters/apps/qwik-city/src/components/sidebar/sidebar.tsx

@@ -1,54 +0,0 @@
-import { component$, Host, useScopedStyles$ } from '@builder.io/qwik';
-import { usePage, usePageIndex } from '@builder.io/qwik-city';
-import styles from './sidebar.css?inline';
-
-export const SideBar = component$(
-  () => {
-    useScopedStyles$(styles);
-    const page = usePage();
-    const navIndex = usePageIndex();
-    if (!page) {
-      return null;
-    }
-
-    return (
-      <Host class="sidebar">
-        <nav class="breadcrumbs">
-          <ol itemScope itemType="https://schema.org/BreadcrumbList">
-            {page.breadcrumbs.map((b) => (
-              <li>
-                {b.text}
-                <meta itemProp="position" content="0"></meta>
-              </li>
-            ))}
-          </ol>
-        </nav>
-        <nav class="menu">
-          {navIndex
-            ? navIndex.items?.map((item) => (
-                <>
-                  <h5>{item.text}</h5>
-                  <ul>
-                    {item.items?.map((item) => (
-                      <li>
-                        <a
-                          href={item.href}
-                          class={{
-                            'is-active':
-                              new URL(page.url, 'https://qwik.builder.io/').pathname === item.href,
-                          }}
-                        >
-                          {item.text}
-                        </a>
-                      </li>
-                    ))}
-                  </ul>
-                </>
-              ))
-            : null}
-        </nav>
-      </Host>
-    );
-  },
-  { tagName: 'aside' }
-);

package/starters/apps/qwik-city/src/entry.dev.tsx

@@ -1,13 +0,0 @@
-import { render } from '@builder.io/qwik';
-import { Root } from './root';
-
-/**
- * Development entry point using only client-side modules:
- * - Do not use this mode in production!
- * - No SSR
- * - No portion of the application is pre-rendered on the server.
- * - All of the application is running eagerly in the browser.
- * - More code is transferred to the browser than in SSR mode.
- * - Optimizer/Serialization/Deserialization code is not exercised!
- */
-render(document, <Root />);

package/starters/apps/qwik-city/src/layouts/default/default.css

@@ -1,171 +0,0 @@
-.docs {
-  --tw-bg-opacity: 1;
-  background-color: rgb(255 255 255 / var(--tw-bg-opacity));
-  --tw-text-opacity: 1;
-  color: rgb(17 24 39 / var(--tw-text-opacity));
-  display: grid;
-  grid-template-columns: 1fr 3fr;
-  grid-template-areas:
-    'header header'
-    'sidemenu content';
-}
-
-.docs header {
-  grid-area: header;
-}
-
-.docs aside {
-  grid-area: sidemenu;
-}
-
-.docs main {
-  margin-left: auto;
-  margin-right: auto;
-  margin-top: 3.5rem;
-  min-height: 100vh;
-  grid-area: content;
-}
-
-.docs article {
-  padding-left: 1.5rem;
-  padding-right: 1.5rem;
-}
-
-.docs article a {
-  color: var(--qwik-dark-blue);
-  text-decoration: underline;
-}
-
-.docs article a:hover {
-  text-decoration: none;
-}
-
-.docs article h1 {
-  --tw-text-opacity: 1;
-  color: rgb(15 23 42 / var(--tw-text-opacity));
-  font-size: 3rem;
-  line-height: 1;
-  font-weight: 700;
-  margin-bottom: 1.5rem;
-  position: relative;
-}
-
-.docs article h2,
-.docs article h3,
-.docs article h4,
-.docs article h5,
-.docs article h6 {
-  font-size: 1.25rem;
-  line-height: 1.75rem;
-  font-weight: 600;
-  --tw-text-opacity: 1;
-  color: rgb(15 23 42 / var(--tw-text-opacity));
-  margin-top: 2rem;
-  margin-bottom: 1rem;
-  position: relative;
-  scroll-margin-top: 80px;
-}
-
-.docs article h2 {
-  font-size: 1.875rem;
-  line-height: 2.25rem;
-}
-
-.docs h2 a,
-.docs h3 a,
-.docs h4 a,
-.docs h5 a,
-.docs h6 a {
-  position: absolute;
-  width: 100%;
-  height: 32px;
-}
-
-.icon-link {
-  display: none;
-}
-
-.icon-link::after {
-  position: absolute;
-  content: '#';
-  left: -23px;
-}
-
-h2 a:hover .icon,
-h3 a:hover .icon,
-h4 a:hover .icon,
-h5 a:hover .icon,
-h6 a:hover .icon {
-  display: inline;
-}
-
-.docs article p {
-  margin-top: 1.25rem;
-  margin-bottom: 1.25rem;
-  font-size: 17px;
-}
-
-.docs article ul,
-.docs article ol {
-  margin-top: 1rem;
-  margin-bottom: 1rem;
-  margin-left: 2rem;
-  font-size: 17px;
-  line-height: 1.7;
-  list-style: disc;
-}
-
-.docs article li {
-  margin-top: 0.25rem;
-  margin-bottom: 0.25rem;
-  padding-left: 0.5rem;
-}
-
-.docs article pre {
-  overflow: auto;
-  color: white;
-  background-color: rgb(1 31 51);
-  padding: 18px 15px;
-  border-radius: 8px;
-}
-
-.docs article pre code {
-  display: block;
-  max-width: 50px;
-  background-color: transparent;
-}
-
-.docs article code {
-  background-color: rgb(224, 224, 224);
-  padding: 2px 4px;
-  border-radius: 3px;
-  font-size: 0.9em;
-  line-height: 1.4;
-}
-
-@media (max-width: 640px) {
-  .docs article code {
-    word-break: break-all;
-  }
-}
-
-.docs article th,
-.docs article td {
-  padding: 6px;
-  vertical-align: top;
-}
-
-.docs article th:first-child,
-.docs article td:first-child {
-  padding-left: 0;
-}
-
-.docs article th:last-child,
-.docs article td:last-child {
-  padding-right: 0;
-}
-
-.docs article img {
-  border-radius: 5px;
-  overflow: hidden;
-}

package/starters/apps/qwik-city/src/layouts/default/default.tsx

@@ -1,24 +0,0 @@
-import { component$, Host, Slot, useScopedStyles$ } from '@builder.io/qwik';
-import { Footer } from '../../components/footer/footer';
-import { Header } from '../../components/header/header';
-import { SideBar } from '../../components/sidebar/sidebar';
-import styles from './default.css?inline';
-
-const DefaultLayout = component$(() => {
-  useScopedStyles$(styles);
-
-  return (
-    <Host class="docs">
-      <Header />
-      <SideBar />
-      <main>
-        <article>
-          <Slot />
-          <Footer />
-        </article>
-      </main>
-    </Host>
-  );
-});
-
-export default DefaultLayout;

package/starters/apps/qwik-city/src/layouts/not-found/not-found.tsx

@@ -1,18 +0,0 @@
-import { component$, Host, useScopedStyles$ } from '@builder.io/qwik';
-import { Header } from '../../components/header/header';
-import { SideBar } from '../../components/sidebar/sidebar';
-import styles from './not-found.css?inline';
-
-const NotFound = component$(() => {
-  useScopedStyles$(styles);
-
-  return (
-    <Host class="docs">
-      <Header />
-      <SideBar />
-      <main>Not Found</main>
-    </Host>
-  );
-});
-
-export default NotFound;

package/starters/apps/qwik-city/src/pages/INDEX

@@ -1,16 +0,0 @@
-# Site struct
-
-## Welcome
-
-- [Welcome](index.mdx)
-
-## Blog
-
-- [Resumable](blog/resumable.mdx)
-- [Progressive](blog/progressive.mdx)
-- [Reactive](blog/reactivity.mdx)
-
-## Docs
-
-- [Qwik](https://qwik.builder.io)
-- [Partytown](https://partytown.builder.io/)

package/starters/apps/qwik-city/src/pages/blog/progressive.mdx

@@ -1,70 +0,0 @@
----
-title: Progressively
----
-
-# Progressively
-
-Progressively is about downloading code as the application needs, without having to download the entire codebase eagerly.
-
-This connect with qwik's core tenant which focus on delaying **the loading** and execution of JavaScript for as long as possible. Qwik needs to break up the application into many lazy loadable chunks to achieve that.
-
-## Current state-of-the-art
-
-[Existing frameworks suffer of two problems](https://www.builder.io/blog/dont-blame-the-developer-for-what-the-frameworks-did):
-
-- Lazy loading boundaries are 100% delegated to the developer
-- Frameworks can only lazy load components that are not in the current render tree.
-
-The issue is that the frameworks need to reconcile their internal state with the DOM. And that means that at least once on application hydration, they need to be able to do a full render to rebuild the framework's internal state. After the first render, the frameworks can be more surgical about their updates, but the damage has been done, the code has been downloaded. So we have two issues:
-
-Frameworks need to download and execute components to rebuild the render tree on startup. (See hydration is pure overhead) This forces eager download and execution of all components in the render tree.
-The event handlers come with the components even though they are not needed at the time of rendering. The inclusion of event handlers forces the download of unnecessary code.
-
-## Solution
-
-Qwik architecture takes full advantage of modern tooling to automate the problem of entry point generation. Developers can write components normally, while the Qwik optimizer will split the components into chunks and download them as needed.
-
-In addition the framework runtime does not need to download code that is not required for interactivity, even if the component is part of the render tree.
-
-### Optimizer
-
-Optimizer is a code transformation that extracts functions into top-level importable symbols, which allows the Qwik runtime to lazy-load the JavaScript on a needed basis.
-
-The Optimizer and Qwik runtime work together to achieve the desired result of fine-grained lazy loading.
-
-Without Optimizer either:
-
-- The code would have to be broken up by the developer into importable parts. This would be unnatural to write an application, making for a bad DX.
-- The application would have to load a lot of unnecessary code as there would be no lazy-loaded boundaries.
-
-Qwik runtime must understand the Optimizer output. The biggest difference to comprehend is that by breaking up the component into lazy-loadable chunks, the lazy-loading requirement introduces asynchronous code into the framework. The framework has to be written differently to take asynchronicity into account. Existing frameworks assume that all code is available synchronously. This assumption prevents an easy insertion of lazy-loading into existing frameworks. (For example, when a new component is created, the framework assumes that its initialization code can be invoked in a synchronous fashion. If this is the first time component is referenced, then its code needs to be lazy-loaded, and therefore the framework must take that into account.)
-
-### Lazy-loading
-
-Lazy-loading is asynchronous. Qwik is an asynchronous framework. Qwik understands that at any time, it may not have a reference to a callback, and therefore, it may need to lazy-load it. (In contrast, most existing frameworks assume that all of the code is available synchronously, making lazy-loading non-trivial.)
-
-In Qwik everything is lazy-loadable:
-
-- Component on-render (initialization block and render block)
-- Component on-watch (side-effects, only downloaded if inputs change)
-- Listeners (only downloaded on interaction)
-- Styles (Only downloaded if the server did not already provide them)
-
-Lazy-loading is a core property of the framework and not an afterthought.
-
-### Optimizer and `$`
-
-Let's look at our example again:
-
-```tsx
-const Counter = component$(() => {
-  const store = useStore({ count: 0 });
-
-  return <button onClick$={() => store.count++}>{store.count}</button>;
-});
-```
-
-Notice the presence of `$` in the code. `$` is a marker that tells the Optimizer that the function
-following it should be lazy-loaded.
-The `$` is a single character that hints to the Optimizer and the developer to let them know
-that asynchronous lazy-loading occurs here.

package/starters/apps/qwik-city/src/pages/blog/reactivity.mdx

@@ -1,155 +0,0 @@
----
-title: Overview
----
-
-# Reactivity
-
-Reactivity is a key component of Qwik. Reactivity allows Qwik to track which components are subscribed to which state. This information enables Qwik to invalidate only the relevant component on state change, which minimizes the number of components that need to be rerendered. Without reactivity, a state change would require rerendering from the root component, which would force the whole component tree to be eagerly downloaded.
-
-# Proxy
-
-Reactivity requires that the framework keeps track of the relationship between the state of the applications and the components. The framework must render the whole application at least once to build the reactivity graph. The build of reactive graph initially happens on the server and is serialized to HTML so that the browser can use the information without being forced to do a single pass through all components to rebuild the graph. (Qwik does not need to do hydration to register events or build up the reactivity graph.)
-
-Reactivity can be done in a few ways:
-
-1. using explicit registration of listeners using `.subscribe()` (for example, RxJS)
-2. using implicit registration using a compiler (for example, Svelte)
-3. using implicit registration using proxies.
-
-Qwik uses proxies for a few reasons:
-
-1. using explicit registration such as `.subscribe()` would require that the system would need to serialize all of the subscribe listeners to avoid hydration. Serializing subscribe closures would not be possible as all the subscribe functions would have to be lazy-loaded and asynchronous (too expensive).
-2. using the compiler to create graphs implicitly would work, but only for components. Intra component communications would still require `.subscribe()` methods and hence suffer the issues described above.
-
-Because of the above constraints, Qwik uses proxies to keep track of the reactivity graph.
-
-- use `useStore()` to create a store proxy.
-- the proxy notices the reads and creates subscriptions that are serializable.
-- the proxy notices the writes and uses the subscription information to invalidate the relevant components.
-
-## Counter Example
-
-```tsx
-const Counter = component$(() => {
-  const store = useStore({ count: 0 });
-
-  return <button onClick$={store.count++}>{store.count}</button>;
-});
-```
-
-1. The server performs an initial render of the component. The server rendering includes creating the proxy represented by `store`.
-2. The initial render invokes the OnRender method, which has a reference to the `store` proxy. The rendering puts the proxy to "learn" mode. During the build-up of JSX, the proxy observers a read to `count` property. Because the proxy is in the "learn" mode, it records that the `Counter` has a subscription on the `store.count`.
-3. The server serializes the state of the application into HTML. This includes the `store` as well as subscription information which says that `Counter` is subscribed to `store.count`.
-4. In the browser, the user clicks the button. Because the click event handler closed over `store`, the Qwik restores the store proxy. The proxy contains the application state (the count) and the subscription, which associates the `Counter` with `state.count`.
-5. The event handler increments the `store.count`. Because the `store` is a proxy, it notices the write and uses the subscription information to invalidate the `Counter`.
-6. After `requestAnimationFrame`, the `Counter` downloads the rendering function and reruns the OnRender.
-7. During the OnRender, the subscription list is cleared, and a new subscription list is built up by observing what reads the JSX building performs.
-
-## Unsubscribe example
-
-```tsx
-const ComplexCounter = component$(() => {
-  const store = useStore({ count: 0, visible: true });
-
-  return (
-    <>
-      <button onClick$={(store.visible = !store.visible)}>{store.visible ? 'hide' : 'show'}</button>
-      <button onClick$={store.count++}>increment</button>
-      {store.visible ? <span>{store.count}</span> : null}
-    </>
-  );
-});
-```
-
-This example is a more complicated counter.
-
-- It contains the `increment` button, which always increments `store.count`.
-- It contains a `show`/`hide` button which determines if the count is shown.
-
-1. On the initial render, the count is visible. Therefore the server creates a subscription that records that `ComplexCounter` needs to get rerender if either `store.count` or `store.visible` changes.
-2. If the user clicks on `hide`, the `ComplexCounter` rerenders. The rerendering clears all of the subscriptions and records new ones. This time the JSX does not read `store.count`. Therefore, only `store.visible` gets added to the list of subscriptions.
-3. User clicking on `increment` will update `store.count`, but doing so will not cause the component to rerender. This is correct because the counter is not visible, so rerendering would be a no-op.
-4. If the user clicks `show` the component will rerender and this time the JSX will read both `store.visible` as well as `store.count`. The subscription list is once again updated.
-5. Now, clicking on `increment` updates the `store.count`. Because the count is visible, the `ComplexCounter` is subscribed to `store.count`.
-
-Notice how the set of subscriptions automatically updates as the component renders different branches of its JSX. The advantage of the proxy is that the subscriptions update automatically as the applications execute, and the system can always compute the smallest set of invalidated components.
-
-## Deep objects
-
-So far, the examples show the store (`useStore()`) was a simple object with primitive values. However, the same behavior works on all properties of the store recursively.
-
-```tsx
-const MyComp = component$(() => {
-  const store = useStore({
-    person: { first: null, last: null },
-    location: null
-  });
-
-  store.location = {street: 'main st'};
-
-  return (
-    <div>
-      <div>{store.person.last}, {store.person.first}</div>
-      </div>{store.location.street}</div>
-    </div>
-  );
-})
-```
-
-In the above examples, the Qwik will automatically wrap child objects `person` and `location` into a proxy and correctly create subscriptions on all deep properties.
-
-The wrapping behavior described above has one surprising side-effect. Writing and reading from a proxy auto wraps the object, which means that the identity of the object changes. This should normally not be an issue, but it is something that the developer should keep in mind.
-
-```tsx
-const MyComp = component$(() => {
-  const store = useStore({ person: null });
-  const person = { first: 'John', last: 'Smith' };
-  store.person = person; // `store.person auto wraps object into proxy`
-
-  if (store.person !== person) {
-    // The consequence of auto wrapping is that the object identity changes.
-    console.log('store auto-wrapped person into a proxy');
-  }
-});
-```
-
-## Out-of-order rendering
-
-Qwik components can render out of order. A component can render without forcing a parent component to render first or to force child components to render as a consequence of the component render. This is an important property of Qwik because it allows Qwik applications to only re-render components which have been invalidated due to state change rather than re-rendering the whole component tree on change.
-
-When components render, they need to have access to their props. Parent components create props. The props must be serializable for the component to render independently from the parent. (See serialization for an in-depth discussion on what is serializable.)
-
-## Invalidating child components
-
-When re-rendering a component, the child component props can stay the same or be updated. A child component only invalidates if the child component props change.
-
-```tsx
-const Child = component$((props: { count: number }) => {
-  return <span>{props.count}</span>;
-});
-
-const MyApp = component$(() => {
-  const store = useStore({ a: 0, b: 0, c: 0 });
-
-  return (
-    <>
-      <button onClick$={() => store.a++}>a++</button>
-      <button onClick$={() => store.b++}>b++</button>
-      <button onClick$={() => store.c++}>c++</button>
-      {JSON.stringify(store)}
-
-      <Child count={store.a} />
-      <Child count={store.b} />
-    </>
-  );
-});
-```
-
-In the above example, there are two `<Child/>` components.
-
-- Every time a button is clicked, one of the three counters is incremented. A change of counter state will cause the `MyApp` component to re-render on each click.
-- If `store.c` has been incremented, none of the child components get re-render. (And therefore, their code does not get lazy-loaded.)
-- If `store.a` has been incremented than only `<Child count={store.a}/>` will re-render.
-- If `store.b` has been incremented than only `<Child count={store.b}/>` will re-render.
-
-Notice that the child components only re-render when their props change. This is an important property of Qwik applications as it significantly limits the amount of re-rendering the application must do on state change. While less re-rendering has performance benefits, the real benefit is that large portions of the applications do not get downloaded if they don't need to be re-rendered.