if it's not broken, fix it until it is.

However at the end of the day I'll stick with whatever Mint decides is best for me. Year in and year out I enjoy a stable, reliable, and consistent environment that "just works" and which thankfully shows very little change between versions. I appreciate that I can pick up a new (to me) laptop and have Mint installed and configured to suit my needs in less than fifteen minutes. And that thereafter I can ignore it, let updates install without worries, and trust that it won't suddenly break itself. Our household includes my two Mint boxes, two Windows 10 laptops, and a shiny new iMac. I'll leave it you to guess which computers have the least issues.

Devuan +1 I've been running it on my main laptop, a local server and a whole bunch of Pis since "ASCII". Recently migrated to "Beowulf" (which incidentally was released yesterday) and was blown away by the speed & quality improvements. It's a superb distro - and I've tried a few, including Ubuntu, Xubuntu, Mint, Alpine, Debian, Red Hat, and others I can't remember

The past few years seems to have be a race between Microsoft and various players in the Linux world to see who can produce the worst abomination of a UI. It's as if there's been a ritualistic burning of the UI design rule book that led to many years of largely stable and consistent user experience across all platforms

Hey, Mint, team! Switch your upstream to Devuan. Because every week, I'm thinking about switching directly there myself...

the Mint team remove all the bad stuff added by Canonical and add better desktop environments. You should try it, you never know, you might like it...

big companies feel more confident if the Linux distribution is being backed/supported by a known commercial entity.

definite good news, as it will hopefully have a ripple effect on crappy chipset makers, getting them to design and test their hardware with Linux properly, for fear of losing all potential business from Lenovo.

I suppose it means 2 things, first, you get official support and warranty, and second, the distros will be Secure Boot approved in the UEFI, instead of distro makers having to figuratively ask Microsoft for pretty please permission.

A bind mount is basically where you mount a given directory on top of an existing one. Suppose you have a RAID array where you have a partition mounted at /home2, containing some larger user accounts. If you wanted to remount /home2/user to /home/user (to sidestep issue #1), without the issues that come along with symlinks (it is not a directory, just a token that points to it), you'd do something like mount --bind /home2/bob /home/bob and the directory will then be traversable from both locations. The target folder must exist, same as any mount point. The end result is somewhat similar to a symlink, but instead of creating a special filesystem object, it utilizes the operating system's filesystem mounting machinery to do it, which makes it more transparent to running software. Tools like 'du' and 'find' will still be aware that they are cross filesystem boundaries, and will also behave as such if the bind mount is entirely within a given filesystem. Finally, as they're transient by nature (unlike symlinks), they need to be placed in fstab or some startup script to make them persistent.

If we're not careful, it could become the new 'systemd' problem It probably already is. I don't want to sound too Stallman, but this is the inevitable "company" influence you'll always have. Companies do have their objectives which they will pursue determinedly, since they are not philanthropic (no judgment, just observation). Systemd and Red Hat. Nvidia and their drivers. Google and Android. Apple and iOS. Manufacturers with MS only support. And Canonical also has a history there: the Amazon links, Unity, Mir, and now snap.

I have nothing against snap in theory, but spamming my mounts, processes, and filesystem is just too darn much

Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice.

"in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can't audit them, hold them, modify them or even point snap to a different store. You've as much empowerment with this as if you were using proprietary software, i.e. none."

What we didn't want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement,"

The Mint developers are resistant, though, saying Snap comes with too much Canonical baggage, and in particular seems tied to the official Snap store.

You can use Chromium from the Debian buster repository. For example, if your Ubuntu release is eoan (19.10):

No, this is not a duplicate of that linked question. I don't need to know "why it's a snap". I want to know how to use it without snap.

It's like patting your head and rubbing your belly, but you're jogging.

Your cat watches (cat not included)

Note that that browser support for these values is nuanced. For example, space-between never got support from some versions of Edge, and start/end/left/right aren’t in Chrome yet

I think you’re missing the spirit behind the classic “centering is hard” complaint in a couple of places, which, at least for me, always comes back to not knowing the height of the elements.

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}

Moving DOM elements around made me anxious and I wanted to preserve natural tab order without resorting to setting tabindex, so I also made a flexbox version that never moves DOM elements around. I think it's the superior solution, at least for the layouts I was going for. https://github.com/wickning1/svelte-components/blob/master/src/FlexCardLayout.svelte

<Masonry> component implementation could be something like this (very drafty)

The CardLayout creates a store in context and the Card creates a standardized div container and registers it to the store so that the CardLayout has access to that DOM element. Then in afterUpdate you can move the DOM elements into columns and Svelte will not try to put them back where they go. It's a bit messy but it works.

It isn’t always guaranteed to be a single root element, in that case it could return an array of elements?

I think that maybe instead of using the prefixed $$ globals, a more "natural" solution could look something like this: import { slots, props, parent } from '@component';

allow <slot> to be part of a slot

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

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="..."/>.

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.

The extra div soup is two fold:

(this issue)

A component reserving a slot but needing to perform manipulation on its content dom reference will need to add an extra element wrapper on the receiving site (some people mention it here: #2106).

A big app will have lots of components compared to regular html elements and these need to be wrapped before being fed to a slot, every single time on the call site

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.

This syntax easily provides all the features of components, like let: bind: and on:. <svelte:fragment /> is just a component with a special name.

If there's a slot attribute that works for elements and (eventually) components, when the desire to pass a component or multiple nodes into a named slot without a wrapper inevitably arises then this syntax seems like a natural extension.

I think this is very important feature to implement. Because for now we need to wrap target components by useless wrapper nodes.

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

Ahh ok, it's a regular let. It's too bad it has to be so intrusive on the call sites.

The <svelte:self> element allows a component to include itself, recursively. It cannot appear at the top level of your markup; it must be inside an if or each block to prevent an infinite loop.

It must be called during the component's initialisation (but doesn't need to live inside the component; it can be called from an external module).

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

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

// read-only, but visible to consumers via bind:start export let start = 0;

export const start = 0

export let start = 0

<svelte-virtual-list-row>

Starter: Free offering that lets you try out DOCR.

Simple answer: If you need the interface in in another module.

Just use import type {AnimType}... instead

export 'InterfaceName' was not found in

Basically the typescript compiler emits no code for interfaces, so webpack can not find them in the compiled module; except when a module consists of only interfaces. In that case the module will end up completely empty and then webpack will not investigate the exports.

On the linked thread I've put details, a suggestion for implementation and an offer of help if someone wants to submit a PR. Let's see what happens!

The behavior of this code is identical, but the implementation is much easier to write and read.

While custom iterators are a useful tool, their creation requires careful programming due to the need to explicitly maintain their internal state. Generator functions provide a powerful alternative: they allow you to define an iterative algorithm by writing a single function whose execution is not continuous. Generator functions are written using the function* syntax.

While it is easy to imagine that all iterators could be expressed as arrays, this is not true. Arrays must be allocated in their entirety, but iterators are consumed only as necessary. Because of this, iterators can express sequences of unlimited size, such as the range of integers between 0 and Infinity.

Can I use the title attribute?Yes. The content prop can be a function that receives the reference element as an argument and returns a string or element.tippy('button', { content(reference) { const title = reference.getAttribute('title'); reference.removeAttribute('title'); return title; }, });The title attribute should be removed once you have its content so the browser's default tooltip isn't displayed along with the tippy.

v1 tabs tightly couple to their v1 Cache; v2 tabs tightly couple to their v2 Cache. This tight coupling makes them “application caches.” The app must be completely shut down (all tabs closed) in order to upgrade atomically to the newest cache of code.

In my opinion, this single-tab Refresh behavior strongly violates the principle of least surprise, and it doesn’t help us to maintain code consistency or data consistency.

Think about how native apps work in your favorite desktop operating system. Er, no, not that one. Think about your favorite popular desktop operating system.

They say that there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. Caching is what Service Workers do. It’s literally the #1 hard thing! … or maybe the #0 thing? Whatever. It’s hard.

If a Service Worker fails, it’s possible to break an entire website in ways that we can’t fix on the server side (or at least, not right away). Imagine this: your site appears to be down, but refreshing the page won’t help, because the browser isn’t even talking to your server; it’s just talking to your broken Service Worker.

As programmers, we sometimes have to work on tricky stuff, but then we say, “Well, it’s not rocket science.” But Service Workers are rocket science.

Oh, silly me, that won’t work. We can’t update index.html at all, so we certainly can’t remove the call to register!

Service Workers are the hot new thing in web APIs. They’re designed to be like the HTML5 Application Cache, but without being objectionable.

“So, what do you do then?” “Oh, I’m the LocalStorage” he replied, shuffling uncomfortably. “I provide a scripting interface for text storage maintained across pages and browser sessions.”

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

I would love to see this features as well, since it makes component composition and reuse a lot easier.

the behavior you want happen is actually a chicken and egg situation, you need to initialise FancyList in order to get the value for let:prop from the FancyList, however you can't initialise FancyList without the value of id which comes from within FancyList.

It's highly recommended you inspect a tippy element via your browser's DevTools. An easy way to do this is to give it hideOnClick: false and trigger: 'click' props so that it stays visible when focus is switched to the DevTools window.

The CSS automatically gets injected into <head> with the CDN (tippy-bundle). With CSP enabled, you may need to separately link dist/tippy.css and use dist/tippy.umd.min.js instead.

TylerRick

Your operating system: Ubuntu 18.04.4 LTS

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.

Now I think it's valid behaviour that reactive statements are not running until onMount is fired.

I've reproduced, in a very simple way, what I would like it to do: https://svelte.dev/repl/2b0b7837e3ba44b5aba8d7e774094bb4?version=3.19.1

I don't know what I'd expect this to do, if not create an infinite loop. You're asking Svelte to do something before every update, and one of the things you're asking it to do is to flush any pending changes and trigger an update.

Can't find the Svelte way of doing this, setTimeout helps now, but this is not a good way working with a framework I think.

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.

TylerRick

The alternative is uncontrolled components, where form data is handled by the DOM itself.

In a controlled component, form data is handled by a React component.

I mean the second one

The third other syntax in your update compiles because Svelte doesn't see that as a conditional bind:this, but as an attribute called bind:this that is conditionally applied. All directives need to be visible at compile time.

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.

Also as an aside, your REPL is far, far too complicated. You've got a much better chance of us being able to see your issue and fix it if you boil it down to just the minimum required code in order to reproduce the issue.

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.

I figured I could try making my own with modern technologies.

The CSS Zen Garden era was hugely inspirational to many.

Monaco is what VScode, and CodeSandBox, use for code editing. It's obviously one of the best code editors in the world. It's always been on my want-to-try-list and this is the perfect proejct.

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

I wanted to use GitHub Gists which are a wonderfully low friction way of sharing code

I wanted to update it to JAMstack

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.

With this setup, we can create a default action that should take place if one wasn’t passed down.

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

While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or edited it to ensure you have an error-free learning experience. It's on our list, and we're working on it! You can help us out by using the "report an issue" button at the bottom of the tutorial.

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

You should default to the most permissive option imo and there really is no reason to check anything until you really need to If it were left to me I'd just use optional chaining, as it also eliminates the need for no-ops

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

be conservative in what you do, be liberal in what you accept from others

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.

answered

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?

If anyone needs this functionality, I've made a primitive approach to forward all standard UI events, plus any others you specify: https://github.com/hperrin/svelte-material-ui/blob/273ded17c978ece3dd87f32a58dd9839e5c61325/components/forwardEvents.js

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.

new Cmp will render to the DOM synchronously, so you don't have to worry about the content flickering because the component is rendered too late.

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

react-spring

Note: your arrow must be an HTMLElement (not an SVGElement). To use an SVG arrow, wrap it in a <div> tag with the data-popper-arrow attribute.

Headless: With React's DOM rendering for improved usage with CSS-in-JS and spring libraries. If you want greater control over your poppers to integrate fully with design systems, this is for you.

We can make content a function that receives the reference element (button in this case) and returns template content:

You can pass the element itself, which is useful for keeping event listeners attached (or when a framework is controlling elements inside):

Ensure HTML strings containing user data are sanitized properly to prevent XSS attacks.

Will only show the tippy while the user is pressing the screen (not a tap)

This is a dynamic value because of hybrid devices which can use a mix of mouse and touch input.

Tippy provides first-class support for touch devices. Tooltips can be tricky to get right on touch devices because of the nature of touch input.

You may want the tippy to appear at a different location from its trigger (event listeners) target. For example:

Context menu

A tooltip is an element containing simple text content describing a particular element. It's hidden until the user desires more information from the element, e.g. before deciding to click a button.

A popover is an interactive HTML tooltip. It can be a dropdown, menu, or any other kind of box that pops out from the normal flow of the document. This type of element contains non-vital functionality and can be hidden behind a click or hover to conserve space.

Both are elements positioned near a "reference" element, and are hidden until they are triggered. They help conserve space by hiding secondary information or functionality behind a hover or click. They are positioned outside the normal flow of the document so when they are triggered, they are overlaid on top of the existing UI without disrupting the flow of content.

Allows you to separate the tippy's positioning from its trigger source.

"Headless Tippy" refers to Tippy without any of the default element rendering or CSS. This allows you to create your own element from scratch and use Tippy for its logic only.

If an element is disabled, you will need to use a wrapper element (<span> or <div>) in order for the tippy to work.

Elements with the disabled attribute aren't interactive, meaning users cannot focus, hover, or click them to trigger a tippy.

It's a generic abstraction for the logic and styling of elements that pop out from the flow of the document and float next to a reference element, overlaid on top of the UI.

Tooltip displayed through long press

just writing in that the example code doesn't work on the REPL... perhaps because it tries to load CSS? I am not sure, but it says “Unexpected token (Note that you need plugins to import files that are not JavaScript)”.

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

const deinitPopper = () => { if (popperInstance) { popperInstance.destroy(); popperInstance = null; } };

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!