533 Matching Annotations
  1. Jul 2021
  2. Jun 2021
    1. Use this to build a ClassAdder component. ClassAdder components are useful for reducing the size of your bundle. If you have tons of simple components that just need to add classes/props or set a context, using ClassAdder components means there's only one "big" Svelte component in your bundle for all of these many tiny components.
    2. This is useful when you need to add classes to a component, since Svelte's "class:" directives don't work on components.
    1. Compared to https://github.com/keenethics/svelte-notifications

        • Nicer styles, animation
        • Can't add one that stays on screen until dismissed. If timeout arg is omitted, it simply defaults to ~3 s.
        • No equivalent to removeNotification or clearNotifications
    1. export function get(req, res) { if (req.headers.authorization) { res.writeHead(200); res.end(JSON.stringify({ message: req.headers.authorization })); } else { res.writeHead(200); res.end(JSON.stringify({ message: 'unauthorized' })); } }
  3. May 2021
    1. if (parsed.protocol) { // external fetch response = await fetch(parsed.href, /** @type {import('node-fetch').RequestInit} */ (opts)); } else { // otherwise we're dealing with an internal fetch const resolved = resolve(request.path, parsed.pathname);
    1. This function runs on every request, for both pages and endpoints, and determines the response. It receives the request object and a function called resolve, which invokes SvelteKit's router and generates a response accordingly.
    2. This allows you to modify response headers or bodies, or bypass SvelteKit entirely
    1. CSR asking my Python backed directly (over nginx). Basically, in my particular situation, I want to use most shorter paths for SSR or CSR cases when I have a separate API server under the same domain and nginx frontend.
    2. on CSR it connects to the svelte-kit endpoint which just use a localhost connection. and to optimize this you can use unix sockets in your endpoints to connect to backend server
    3. ah you are talking about a external api endpoint server? then you could use the svelte-kit endpoints as proxy handler
    1. This looks cool but right now, let's say i have an external api which depends on users cookies, the cookies only gets send through internal sk endpoints while ssr even if its the same domain. Couldn't we pass the 'server' request to the serverFetch hook? I would currently have to patch package svelte kit to pass request headers to the external api or create an sk endpoint which proxies the request.
    1. The thing that makes the client-side invocation return the same data as the server-side one is that the results of calling fetch during SSR are serialized and inlined into the page. This ensures consistency when the page hydrates, and saves network round-trips (and also means less data needs to come over the wire, since everything can get compressed using the same gzip dictionary or whatever).
  4. Mar 2021
    1. My preference here is biased by the fact that I spend everyday at work building web components, so Svelte's approach feels very familiar to slots in web components.

      first sighting: That <template>/<slot> is part of HTML standard and the reason Svelte uses similar/same syntax is probably because it was trying to make it match / based on that syntax (as they did with other areas of the syntax, some of it even JS/JSX-like, but more leaning towards HTML-like) so that it's familiar and consistent across platforms.

    2. The codebase for Pomodone makes more sense to me in Svelte, not React. I find it easier to navigate and work with.
    3. React and Svelte are very similar in many ways, but what I've found is that in all the little ways that they are different, I prefer Svelte.
    4. but I like that Svelte comes with a good CSS story out the box.

      comes with a good CSS story out the box

    5. I like this approach more because I can scan the code that renders the Box component and easily spot that it takes two children. If the Box took any props, they'd be within the opening <Box> tag, and they would be distinct from any children props.
    6. Coming from React to Svelte this did catch me out numerous times but for me I now prefer Svelte's approach, particularly because it removes some of the boilerplate around useEffect.
    7. Svelte is different in that by default most of your code is only going to run once; a console.log('foo') line in a component will only run when that component is first rendered.
    8. I was pleasantly surprised by Svelte's templating; in the past I've found templating languages overwhelming and inflexible, but Svelte offers just the right amount of templating whilst enabling you to use JavaScript too.
    9. Svelte looks pretty similar, but has two small changes that personally make the Svelte code easier to read, in my opinion:
    10. What I like is that currentUser isn't a value, it's a store, and therefore you have full control over how you deal with it.
    11. Talking of context, that's much closer to the approach I take with Svelte and use a writable store.
  5. Jan 2021
    1. Maybe $$slots like $$props? My use case is that I'd like to wrap a slot's content in an element that applies styling that I'd like absent without the slotted content. Something like this: {#if $$slots.description} <div class="description"> <slot name="description"></slot> </div> {/if}
    1. allow <slot> to be part of a slot
    2. But it doesn't work so I have to wrap slots in useless and interfering divs or spans like this: <Button fz="16" h="64" {...$$props}> <span slot="prepend"><slot name="prepend" /></span> <slot /> <span slot="append"><slot name="append" /></span> </Button>

      It really doesn't work? I thought, from @tanhauhau's example, that it would, right?

    3. I want to make some add-ons or wrappers on components e.g BigButton.svelte <script> import Button from './Button.svelte' </script> <Button fz="16" h="64" {...$$props}> <slot slot="prepend" name="prepend" /> <slot /> <slot slot="append" name="append" /> </Button>
    4. Related to #1824, can do <svelte:component this={Bar}> <slot></slot> <slot name="header" slot="header"></slot> </svelte:component> <script> import Bar from './Bar.svelte'; </script> as a forwarding workaround
    1. Interesting . That feature (<slot slot="..."/>) was only recently added in #4295. It wasn't primarily intended to be used that way, but I guess it's a good workaround for this issue. I'm yet to find caveats to slotting components that way, other than it's inconvenient, as opposed to <Component slot="..."/>.
    2. I'm not sure I understand the point of what you're trying to do. Components inherently have no root node so there isn't just one "node slotted" that you could possibly reference. <slot slot=""> doesn't create a wrapper around your component in the DOM. It just injects your component as Svelte usually would.
    3. If components gain the slot attribute, then it would be possible to implement the proposed behavior of <svelte:fragment /> by creating a component that has a default slot with out any wrappers. However, I think it's still a good idea to add <svelte:fragment /> so everyone who encounters this common use case doesn't have to come up with their own slightly different solutions.
    4. Another possible syntax is {#slot bar}<Foo/>{/slot}, which would also allow a bunch of DOM nodes and components inside the slot, without them needing to be from a single component
    1. In 3.29.0 you can now use <slot slot='...'> to forward slots into a child component, without adding DOM elements.
    2. Would love to see passthrough slots to create superset components, for example Table and TableWithPagination (table slots for TableWithPagination could be passed through to Table).
    1. From a community POV, Svelte Summit should probably be mentioned, the YouTube channel has most of the recordings uploaded as standalone videos now (there is a playlist here ).
    1. Knowing exactly what happens in your application can mean the difference between feeling in full control or experiencing deep frustration. Personally, unknowns drive me crazy, which in turn often leads to all sorts of experiments and/or debug sessions.
    1. Note that the value of canvas will be undefined until the component has mounted, so we put the logic inside the onMount lifecycle function.
    1. beforeUpdate(async () => { console.log('the component is about to update'); await tick(); console.log('the component just updated'); });
    1. But Svelte doesn't work like that - all css is statically compiled, and changing myCSS doesn't update the head component.
    1. And this way also fits more with data down, actions up.
    2. So you might ask what is the benefit of using the event dispatcher over just passing a prop down? In some scenarios, you will need to add an action to a button that is 3 or more components down and passing a prop all that way is considered prop drilling (it is frowned upon by some, meh each to their own). However in the case of using an event dispatcher, even though these events don’t bubble, we can easily pass them up using a shortcut that Svelte has.
    3. Depending on what other component libraries you’ve used, you may be used to handling events by passing callback functions to component properties, or using a special event syntax – Svelte supports both, though one is usually more appropriate than the other depending on your situation. This post explains both ways.
    1. It’s something that we’re already used to do naturally with HTML elements. Let’s demonstrate how using the <slot> component works by building a simple Card component
    1. If it's behaviour that you can imagine needing to reuse among multiple components, or if it's something that you can imagine applying to an element inside an {#if ...} block (for example), then it probably belongs in an action. It it's something that 'belongs' to the component itself, rather than a specific element, then it's probably more of a lifecycle thing.
    2. The use:action method seems cleaner, but aside from that, are there any underlying differences between these two methods that would make one preferred over the other in certain situations?
    1. A Svelte component that monitors an element enters or leaves the viewport/parent element. Performant and efficient thanks to using Intersection Observer under the hood. Can be used in multiple projects including lazy loading images, infinite scrolling, playing/pausing the video when in the viewport, tracking user behaviour firing link pre-fetching and animations and many many more.
    1. // super-simple CSS Object to string serializer const css = obj => Object.entries(obj || {}) .map(x => x.join(":")) .join(";");
    1. Popper for Svelte with actions, no wrapper components or component bindings required! Other Popper libraries for Svelte (including the official @popperjs/svelte library) use a wrapper component that takes the required DOM elements as props. Not only does this require multiple bind:this, you also have to pollute your script tag with multiple DOM references. We can do better with Svelte actions!
    1. {#each charts as chart, i} <div class="wrapper"> <div class="icon" on:click={e => instances[i].handle(e)}>Click</div> <div class="content"> <svelte:component this={charts[i]} bind:this={instances[i]} /> </div> </div> {/each} ...where each child component exports a handle method: <script> let event; export function handle(e){ event = e; }; </script>
    1. If you manage to make Svelte aware of what needs to be tracked, chances are that the resulting code will be more performant than if you roll your own with events or whatever. In part because it will use Svelte's runtime code that is already present in your app, in part because Svelte produces seriously optimized change tracking code, that would be hard to hand code all while keeping it human friendly. And in part because your change tracking targets will be more narrow.
  6. Dec 2020
    1. The more I think about this, the more I think that using the context API (for all the stores — page, preloading and session) is the most regret-proof approach, using the proposal above

      Looks like this is the approach that they went with

    1. session can be used to pass data from the server related to the current request. It is a writable store, meaning you can update it with new data. If, for example, you populate the session with the current user on the server, you can update the store when the user logs in. Your components will refresh to reflect the new state
    2. Preload functions are typically used to load data that the page depends on, hence its name. This avoids the user seeing the page update as it loads, as is typically the case with client-side loading.
    1. With this change, we can re-run preload when the session store changes, e.g. as a result of something like this in a nav bar:
    2. I have a feeling that this functionality is scuppered by #415 - since my browser caches the page for 10 minutes, meaning that the page is never hit and thus the preload is never run, regardless of whether session has been changed or not.
    1. I'd instinctively associate a this.cache() inside preload with the preloaded data only -- meaning no matter what crazy thing I did inside preload, the returned data would be cached locally, where local means either the client or server.
    1. Just realised this doesn't actually work. If store is just something exported by the app, there's no way to prevent leakage. Instead, it needs to be tied to rendering, which means we need to use the context API. Sapper needs to provide a top level component that sets the store as context for the rest of the app. You would therefore only be able to access it during initialisation, which means you couldn't do it inside a setTimeout and get someone else's session by accident:
    1. I put together a POC that resembles react-rails and helps with server- and client-side rendering, and provides a view helper (svelte_component):
    2. webpacker-svelte misses server-side rendering, though.
    1. People really don't stress enough the importance of enjoying what you're programming. It aids creativity, makes you a better teammate, and makes it significantly easier to enter a state of flow. It should be considered an important factor in choosing a web development framework (or lack thereof). Kudos!
    1. Now that I got a clearer picture, I still don't understand why that error message (cannot bind to variable declared with let:) is there, in the sense that for me it would make a lot of sense to both bind (which connects bidirectionally the App#item variable with the Component#item variable) and also let (which connects the slot#item variable with the Component#item variable, allowing data to flow from slot to Component, and thus to the top-level App via the bind syntax.
    2. Binding In a nutshell, the purpose of this is to update the variable programmatically or when the DOM element/components updates it.
    1. Is using bleeding edge tech risky and foolish? How much blood are we talking about? My experience tells me Svelte is a safe choice, more leading edge than bleeding.
    2. Svelte is its own language, not plain HTML+CSS+JS

      its own _

    3. React abstracts the DOM with functionally pure declarative rendering and provides escape hatches back to mutable imperative DOM land. This is a profound philosophical difference that Rich gave a talk about.
    4. Making UIs with Svelte is a pleasure. Svelte’s aesthetics feel like a warm cozy blanket on the stormy web. This impacts everything — features, documentation, syntax, semantics, performance, framework internals, npm install size, the welcoming and helpful community attitude, and its collegial open development and RFCs — it all oozes good taste. Its API is tight, powerful, and good looking — I’d point to actions and stores to support this praise, but really, the whole is what feels so good. The aesthetics of underlying technologies have a way of leaking into the end user experience.
    5. It's true that Svelte does not allow you to map over children like React, but its slot API and <svelte:component> provide similarly powerful composition. You can pass component constructors as props and instantiate them with <svelte:component>, and use slots and their let bindings for higher order composition. It sounds like you're thinking in virtual DOM idioms instead of Svelte's.
    6. since the Svelte compiler actually does useful things (I have the same opinion on TypeScript). I love the idea of actual reactivity, rather than re-render + diff based solutions like React.
    7. These are valid comments. I think it is worth noting that svelte didn’t choose a non-javascript method for fun or because we think we should redesign the language. The additional constructs, for the most part, are there to allow svelte to more clearly work out exactly what is going on in the code in order to optimise. In short svelte needs a certain amount of information to do what it does and pure javascript is often difficult to analyse in this way. But I appreciate your concerns and comments and we try to take all feedback on board where we can. So thank you!
    8. My frustration is mainly from Svelte's choices that are very un-JavaScript-like. It doesn't have to be "like React/Vue". React is React because it doesn't restrict what you can do with JavaScript for the most part. It's just common FP practice to fold/map.
    1. Don't worry about the fact that we're redeclaring the foo function for every component instance — Svelte will hoist any functions that don't depend on local state out of the component definition.