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

Since this is a recursive component I can imagine it being tricky to oversee all the slots and props passing.

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>

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>

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

I am trying to implements this usecase (a generic lazy loader component which forwards slots/events to the "real" component).

In 3.29.0 you can now use <slot slot='...'> to forward slots into a child component, without adding DOM elements.

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).

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 ).

Or just watch the value with a reactive statement instead of an event handler on the input like: $: inputValue, onInput() This is a good solution and seems to work in all cases.

What I think is happening is that instantiating the component is immediately running the $: reactive code, which dispatches the event synchronously, before the parent component attaches the listener.

Thanks to that I have chance and time to properly initialise all the properties without reactive calls and I do not have to ignore these "initialising" events before proper initialisation.

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.

Note that the value of canvas will be undefined until the component has mounted, so we put the logic inside the onMount lifecycle function.

It's more powerful to have them happen in definition order, because this lets you intercept thing in event handlers or in actions.

If you're using webpack with svelte-loader, make sure that you add "svelte" to resolve.mainFields in your webpack config. This ensures that webpack imports the uncompiled component (src/index.html) rather than the compiled version (index.mjs) — this is more efficient.

beforeUpdate(async () => { console.log('the component is about to update'); await tick(); console.log('the component just updated'); });

But Svelte doesn't work like that - all css is statically compiled, and changing myCSS doesn't update the head component.

And this way also fits more with data down, actions up.

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.

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.

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

But that method has its limitations. The <slot> directive cannot be dynamic.

Moreover, you can add as many use:action directives as you want to an element.

With a few lines of code we can add functionality to regular HTML elements, in a very reusable and declarative way.

the use directive takes care of the component lifecycle for us.

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.

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?

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.

It should be as simple to use as in the days of jQuery's tooltips.

// super-simple CSS Object to string serializer const css = obj => Object.entries(obj || {}) .map(x => x.join(":")) .join(";");

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!

A cleaner approach could be the use:action API.

{#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>

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.

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

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

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.

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:

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.

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.

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:

I put together a POC that resembles react-rails and helps with server- and client-side rendering, and provides a view helper (svelte_component):

webpacker-svelte misses server-side rendering, though.

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!

I agree with your first point about the presumed complexity of slots.

Fixes #1037 allow slotted components via making <Component> <Inner slot="foo" /> </Component> as a sugar syntax for <Component> <svelte:fragment slot="foo"> <Inner /> </svelte:fragment> </Component>

Oof. Slots are complicated

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.

Binding In a nutshell, the purpose of this is to update the variable programmatically or when the DOM element/components updates it.

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.

Svelte is its own language, not plain HTML+CSS+JS

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.

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.

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.

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.

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!

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.

It seems being able to bind:this={slotEl} directly on a slot element is a popular request. I'll add my +1 as adding div wrappers just to get dom references gets old really fast.

Slot element doesn't support bind:this, but it's fallback child does.

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.

I think the main difference between the two are the way API are served. Some smelte components need you to input big chunk of json as props, while i prefer keep props as primitive types and in the other hand give you different components tags to compose.

Really? I've been using Flutter for about a week and Svelte seems an order of magnitude better designed. I find Flutter overly complicated.

Svelte by itself is great, but doing a complete PWA (with service workers, etc) that runs and scales on multiple devices with high quality app-like UI controls quickly gets complex. Flutter just provides much better tooling for that out of the box IMO. You are not molding a website into an app, you are just building an app. If I was building a relatively simple web app that is only meant to run on the web, then I might still prefer Svelte in some cases.

Before showing the final result of the .svelte components we will also add Material-UI, using the adapted version.

There is no rerender, when you call listen, then all scroll events will warn on chrome. See this entry from svelte: breaking the web

For use$ since svelte is never going to support actions for components, i designed something that reminds React hooks that will in some ways replace this feature.

I agree, it would be great to join forces and speed up development... Svelte really needs one safe material library option.

If I understand the problem correctly, just changing the imports to point to svelte/internal isn't enough because they could still point to different packages depending on how your components are bundled. It solved your specific issue, but if you had two completely unrelated Svelte components compiled to vanilla javascript bundled with Svelte, you'd still hit issues with mismatching current_component when using slots or callbacks.

It sounds like another case of multiple svelte/internal modules? I think we need to look into reworking how svelte/internal keeps track of the current component since it breaks when mixing components not bundled with the app. It sounds like we need to find a way to pass Svelte's internal runtime state when instantiating components, since slots and callbacks end up mixing different svelte/internal together.

As mentioned in #2937, this is the sort of thing that happens when you have two copies of Svelte's internal scheduler running. If you're importing the compiled version of an external Svelte component into another Svelte component, this is what you end up with. There's a svelte field in package.json that's respected by rollup-plugin-svelte and which is intended to point at the uncompiled Svelte source, so that the external component can be bundled together with the main app, without any duplicated internals.

DOM element binding using the bind:this attribute doesn't work apparently

When using the exact same Button code, the binding only works for the local Svelte module.

In the past, I tried to create some proof of concepts with svelte, but I usually ended up missing some of the features that RxJS provides. Now that I know that they complement each other well, I will grab this combination more often

For me, this makes Svelte the most reactive "framework" at the moment

class SvelteSubject extends BehaviorSubject

Another difference is that context in Svelte does not insert anything into the visual component tree. There is no <Context.Provider> element like in React

In Svelte, all reactive statements are memoized. Instead of const var = useMemo(() => expression, dependencies), you can use $: var = expression. Notice with Svelte, you don't need to declare the dependencies. The compiler infers them for you.

Because of those similarities, it's possible to automate some of the changes.

Those frameworks are used in a similar fashion, but conceptually use quite different approaches (Vue is a more traditional one, a library, and Svelte is a "dissapearing framework").

The main point — each framework/library/instrument has some kind of flaw, something it handles a little worse than others. And Svelte is no exception.

To bundle this in your own code, use a Sass processor (not a Sass Svelte preprocessor, but a Sass processor)

You can add actions to the components with use={[Action1, [Action2, action2Props], Action3]}.

Although Capacitor is developed by Ionic, you can use it in combination with any framework and UI library you want. In fact, Capacitor itself promotes using it with whatever framework you want.

I encounter this problem in all of my Svelte projects- feels like I'm missing something. Fighting it with absolute positioning usually forces me to re-write a lot of CSS multiple times. Is there is a better way to solve this that I've overlooked?

I came over from Vue as well, the out-in is one thing I miss with Svelte. Rich Harris even acknowledged it prior to Svelte 3 but never really implemented a fix as far as I'm aware.

Svelte's stances