Insisting on a specific implementation, rather than proposing a clear problem, suggesting a possible solution, and “not being married” to your initial preferred solution.

Modules using code that doesn’t exist in browsers such as process.env.NODE_ENV and forcing you to convert or polyfill it.

The benefit of this approach is that rather than having these defaults and fighting against them, it’s fully up to you to decide how to handle everything.

Instead, rather than trying to implement what it thinks is the best way to bundle different type of assets, it leaves that entirely up to the developer to decide.

Personally for me, this is incredibly hard to read. Regex everywhere, nested objects with different rules and configurations that are very intuitive, multiple loaders that resolve backwards, built in loaders having obscure issues that require using third party loaders in between, separation of plugins and loaders, and so on.

In my opinion, because Webpack was one of the first bundlers, is heavily packed with features, and has to support swathes of legacy code and legacy module systems, it can make configuring Webpack cumbersome and challenging to use. Over the years, I’ve written package managers, compilers, and bundlers, and I still find configuring Webpack to be messy and unintuitive.

Unfortunately, many third party libraries, even though they are written in ESM, are published to npm as CJS modules, so we still need to concatenate them.

Wow, no answers to this question. That's too bad. Did you ever find the solution?

Did you know that you can create a Svelte component and with almost no extra steps distribute- and use it like any classic old Javascript library through a global constructor (let myComponent = new MyComponent())?

So I guess what @Rich-Harris is trying to say is that (sorry, I'm just logging it here for my own benefit)

we've learned why you might want to use external but not globals: libraries. We've started to factor some of our client-side JS as libraries to share between projects. These libraries import $ from 'jquery'. However they don't want to presume how that import might be "fulfilled". In most projects it's fulfilled from a global i.e. a script loaded from a CDN. However in one project it's fulfilled from a local copy of jQuery for reasons I won't get into. So when these libraries bundle themselves for distribution, as ES6 modules, they mark 'jquery' as an external and not as a global. This leaves the import statements in the bundle. (Warning: Don't bundle as an IIFE or UMD, or Rollup will guess at fulfilling the import from a global, as @Rich-Harris mentions above.)

There are two ways of handling this with Rollup, as described by the troubleshooting link from the warning. Unfortunately, both Rollup and React recommend the wrong one.

Luckily, there is absolutely no good reason not to use strict mode for everything — so the solution to this problem is to lobby the authors of those modules to update them.

small modules allow library authors to become lazy. Why include that six-line helper function when you can do a one-line `require`?

These are all things that make your life as a library author easier.

This happens because npm makes it ridiculously easy for people to release their half-baked experiments into the wild. The only barrier to entry is the difficulty of finding an unused package name. I’m all in favour of enabling creators, but npm lowers the barriers right to the floor, with predictable results.

I think I know why: it’s because the small modules philosophy favours library authors (like Sindre) at the ultimate expense of library users.

I hope I won’t forget, but I’ll come back to you once we’ve got an idea on how to improve this Svelte API

DX: start sapper project; configure eslint; eslint say that svelt should be dep; update package.json; build fails with crypt error; try to figure what the hell; google it; come here (if you have luck); revert package.json; add ignore error to eslint; Maybe we should offer better solution for this.

When the message say function was called outside component initialization first will look at my code and last at my configuration.

GitHub issues aren't the right place for support questions like this. Please ask on StackOverflow or in our Discord chat room.

The recommended solution for onMount is the same as for useEffect — place an async function inside the handler

(Note that you're responsible for handling any race conditions that arise as a result of the component being destroyed before the promise resolves, though assigning state inside a destroyed component is harmless.)

Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.

Also Svelte is so great because developer do not need to worry about class names conflict, except of passing (global) classes to component (sic!).

I wrote hundreds of Rect components and what I learned is that Componets should be able to be styled by developer who is using it.

Just throwing in <div class="{$$props.class || ''} otherChildClass"></div> seems the easiest, and it'll avoid undefined classes. I feel like many aren't noticing the undefined values getting inserted in their classes.

color: red; //doesn't apply this rule, because scoping doesn't extend to children

Say I want to style this javascript routing anchor tag on various pages (some may be buttons, plain links, images) it makes it incredibly difficult. Eg:

TBH It is a bit disheartening to see this issue closed when all proposed solutions do not sufficiently solve the issue at hand, I really like svelte but if this is how feature requests are handled I am probably not going to use it in the future.

The language should work for developers, not the other way around.

Having to wrap everything in a selector :global(child) { } is hacky

I think instead, there would need to be some special way to make the distinction of what is a slot attribute and what is a slot prop to be consumed with let:. Maybe a new directive like <slot attr:class="abc"/>?

I can't add special props and keywords to every single component I have and will ever create for this to work.

There are work arounds, but nothing clean. I just feel like this should be functionality that should be part of the slot feature.

Explicitly exposing any attributes that might get overridden by a parent seems impractical to me.

feel like there needs to be an easy way to style sub-components without their cooperation

There's no way to change style incapsulation method without patching the compiler, and this means maintaing a fork, which is not desirable.

The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.

There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.

Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.

Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.

If you want this control then wrap them in a DOM node that the parent controls. If you want to pass in values then use props and if you want to pass in values from higher up the tree, the new style RFC may be able to help.

new style RFC

This allows passing classes to child components with svelte-{hash} through the class prop and prevents removing such classes from css.

I think this is being rejected on grounds that are too arbitrary, and detract from what to me are the best things about Svelte -- it's fun and easy to use, and lets you write components in a way that's natural and expressive.

Web developers are well aware of the mess you can get into with global CSS, and the action of writing <Child class="foo"/> and <div class={_class}>` (or similar) in the child component is an explicit indication that, while taking advantage of all the greatness of style encapsulation by default, in this case you have decided that you want a very specific and controlled "leak", of one class, from one component instance to one component instance.

Would style .classInChild from your parent. The only drawback is that you might need an extra wrapping element.

This has already forced me to forgo Svelte Material because I would like to add some actions to their components but I cannot and it does not make sense for them to cater to my specific use-case by baking random stuff into the library used by everyone.

The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.

For my simple tooltip example, I could create a TooltipHitbox component with a <slot/> inside a <div use:myTooltip={tooltipProp}> and then wrap MatButton instances with that component.

I think Svelte's approach where it replaces component instances with the component markup is vastly superior to Angular and the other frameworks. It gives the developer more control over what the DOM structure looks like at runtime—which means better performance and fewer CSS headaches, and also allows the developer to create very powerful recursive components.

Lets not extend the framework with yet another syntax

Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.

I totally get not wanting to extend the syntax. I tried doing these things and in practice it was not easy or pretty. Actions provide a much cleaner and easier way to accomplish a certain set of functionality that would be much more difficult without it.

<LazyLoad component="img" data-src="giant-photo.jpg" class="my-cool-image" />

Why not just do something like this?

I'm still confused about the need for this, so at the expense of continuing to be that obnoxious kid at the playground, I'm going to stick my neck out again.

Devil's advocate: I'm not convinced the functionalities you list can't already be done within the JS of the component. Example: autofocus can simply be done w/ a method or oncreate.

Actions aren't necessary, otherwise they would have been implemented from the start. But they do allow for easier code-reuse and better shared libraries without exploding/complicating the ecosystem.

You'll have to create a new component that brings in the functionality of both. TooltipButton, TooltipLink, Link, and TooltipRoutedLink. We're starting to get a lot of components to handle a bit of added functionality.

For the tooltip example, if you had a whole bunch of tooltips on different elements, it would be annoying to have different event listeners and "should it be shown" variables for each one.

I'm just pushing on the "is this really a good idea" front

If this was tied into Svelte's flow with hooks this would not be necessary since it would know when it was being removed from the DOM.

You must: reference each element you are extending using refs or an id add code in your oncreate and ondestroy for each element you are extending, which could become quite a lot if you have a lot of elements needing extension (anchors, form inputs, etc.)

This is where hooks/behaviors are a good idea. They clean up your component code a lot. Also, it helps a ton since you don't get create/destroy events for elements that are inside {{#if}} and {{#each}}. That could become very burdensome to try and add/remove functionality with elements as they are added/removed within a component.

I would be willing to take a stab at it if you think it would be a task within reach.

This can and should be done with other components, IMHO.

the ability to pass around element names as strings in place of components

I'm a lot softer on this feature now - I'm starting to believe that every single use case that you would use a hook for, you could/should use a component for.

Perhaps at that point we're better off settling on a way to pass components through as parameters? <!-- App.html --> <Outer contents={Inner}/> <!-- Outer.html --> <div> <div>Something</div> <[contents] foo='bar'/> </div>

But some sort of official way to do that in the language would make this nicer - and would mean I would have to worry less about destroying components when their parent is destroyed, which I'm certainly not being vigilant about in my code.

I would hope for it to come with React-like behavior where I could pass in a string (like div or a) and have it show up as a normal div/a element when the child component used it.

The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)

Also, I'm starting to wonder if maybe it's okay to have multiple spreads? If the alternative to <Foo {...a} {...b} {...c} d={42}> is that people will write <Foo {...Object.assign({}, a, b, c)} d={42}> anyway, then do we gain anything with the constraint?

I'll work on a preliminary PR (which I expect will need some love from maintainers, sorry!)

The lack of spread continues to be a big pain for me, adding lots of difficult-to-maintain cruft in my components. Having to maintain a list of all possible attributes that I might ever need to pass through a component is causing me a lot of friction in my most composable components.

No worries, I was just thinking that this issue should probably get necro'd back to open.

No, this is about using a string to create an element of that tag name.

Use case: Wrapper components that need to render an element (e.g. because they attach event listeners). You'd probably use a <div> there by default but there may be places where this is not desirable for semantic reasons (e.g. in lists).

{#each section as {tag, is_self_closing, props, content}} {#if is_self_closing} <{tag} {...props} /> {:else} <{tag} {...props}>{content}</{tag}> {/if}

const components = { Label, Tree, Menu };

Note that Array.entries() returns an iterator, which is what allows it to work in the for-of loop; don't confuse this with Object.entries(), which returns an array of key-value pairs.

The value of dotAll is a Boolean and true if the "s" flag was used; otherwise, false. The "s" flag indicates that the dot special character (".") should additionally match the following line terminator ("newline") characters in a string, which it would not match otherwise: U+000A LINE FEED (LF) ("\n") U+000D CARRIAGE RETURN (CR) ("\r") U+2028 LINE SEPARATOR U+2029 PARAGRAPH SEPARATOR This effectively means the dot will match any character on the Unicode Basic Multilingual Plane (BMP). To allow it to match astral characters, the "u" (unicode) flag should be used. Using both flags in conjunction allows the dot to match any Unicode character, without exceptions.

Part of the functionality that is returned are event handlers. I'd like to avoid needing to manually copy the events over one by one so the hook implementation details are hidden.

The feature is highly likely to be implemented, the API and implementation are the only real topics of discussion right now.

Three tests to prove a small piece of behavior. Although it might seem overkill for such a small feature, these tests are quick to write—that is, once you know how to write them

To learn about canceling fetch requests, search the internet for

You should install the packages individually. Alternatively, you can install all of them at once with the svelte-material-ui package.

I don't plan to push this to npm, cause I'm in favour with Deno's approach.

In a similar vein to (#33), it is arguably just something that compensates for the lack of power in the template language relative to JavaScript.

However, we've another unresolved problem - passing parent's styles to child components.

Even without going to that extreme, the constraint of having a single <style> can easily force component authors to resort to the kinds of classes-as-namespaces hacks that scoped styles are supposed to obviate.

6to5 attempted to ship a quick and dirty TDZ static checking feature but had to retract it immediately afterwards due to various bugs in the algorithm.

The complaint is that by choosing less powerful languages, template-based frameworks are then forced to reintroduce uncanny-valley versions of those constructs in order to add back in missing functionality, thereby increasing the mount of stuff people have to learn.

Please focus on explaining the motivation so that if this RFC is not accepted, the motivation could be used to develop alternative solutions. In other words, enumerate the constraints you are trying to solve without coupling them too closely to the solution you have in mind.

GitHub Issues are preferred for discussion of this specification.

There are tools in Svelte that break this expectation to a degree, but they are a bit annoying to use, which makes it an active decision on the part of the developer. The API hints at the way we want you to do things because we feel that this will give the better experience.

Most of the linked issues, as well as this RFC, attempt to solve this problem by relaxing Svelte's CSS scoping rules, providing a better API with which to use global, or by manually passing down classes. We have never found this to be an acceptable solution which is why those issues have been closed. That position has not changed.

:global just feels like a hack for a feature that should already be there.

Or if we formally took a stance that the class prop is THE ordained way to pass class attributes, though I don't think this functionality warrants this restriction.

But if you’ve spent time building front ends with components, it’s hard to go back. Svelte lets us do that with a minimum of fuss or code bloat.

With Svelte, components and files have a one-to-one relationship. Every file is a component, and files can't have more than one component. This is generally a "best practice" when using most component frameworks.

It was called a "virtual DOM" library because it didn't start out as isomorphic, but actually tied to the DOM from the start. It was an afterthought to make it isomorphic.

Materialism and the Dialectical Method

Circe by Madeline MillerThis magnificent story of the famous witch goddess from Homer’s Odyssey was shortlisted for the 2019 Women’s prize for fiction. It is both hugely enjoyable, showing the very male classical epic from a female point of view, and profoundly affecting in its depictions of the trials of immortality. This book is the closest you can get to experiencing what it might really be like to be a goddess, with all its benefits and sacrifices.

This is easily solved by extracting components, either as template partials/JavaScript components, or using Tailwind's @apply feature to create abstractions around common utility patterns.

Now I know what you're thinking, "this is an atrocity, what a horrible mess!" and you're right, it's kind of ugly. In fact it's just about impossible to think this is a good idea the first time you see it — you have to actually try it.

When you visit location /one and the server redirects you to location /two, you expect the browser’s address bar to display the redirected URL. However, Turbolinks makes requests using XMLHttpRequest, which transparently follows redirects. There’s no way for Turbolinks to tell whether a request resulted in a redirect without additional cooperation from the server. To work around this problem, send the Turbolinks-Location header in the final response to a visit that was redirected, and Turbolinks will replace the browser’s topmost history entry with the value you provide.

It’s harder to read code than to write it

React doesn’t provide something like ng-class, but there is a great library called classnames that does the same and more. Install it:

Force everything to the git root per NPM lameness

For a non-monorepo package you can simply point directly to the Github repo. This case is similar, but you want to scope it just to a single package within the repo. For those that make monorepos they don't necessarily need this feature. It's for those that use projects that use monorepos. Telling them to not organize their projects into monorepos doesn't help people who make use of these projects.

npm's inability to handle monorepos then i'd have designed my repos accordingly

There are other mathematical models of institutionalized bias out there! Male-Female Differences: A Computer Simulation shows how a small gender bias compounds as you move up the corporate ladder. The Petrie Multiplier shows why an attack on sexism in tech is not an attack on men.

Schelling's model gets the general gist of it, but of course, real life is more nuanced. You might enjoy looking at real-world data, such as W.A.V. Clark's 1991 paper, A Test of the Schelling Segregation Model.

Can you try to delete node_modules folder and package-lock.json file.

clean node_modules

Between each step I did rm -rf node_modules package-lock.json && npm i. Just to be sure

Any typescript definitions exported from this library should be tested, otherwise it can cause real pain and doubt for ts users.

Figures like Kenneth Hagin, his protégé Kenneth Copeland, Oral Roberts, and, of course, Osteen himself built up individual followings: followings that often grew as a result of cross-promotion (something religious historian Kate Bowler points out in her excellent Blessed, a history of the prosperity gospel movement). One preacher might, for example, feature another at his conference, or hawk his cassette tapes.

James Suzman’s ‘Work: A History of How We Spend Our Time’ is published next month by Bloomsbury.

Triggers error messages to render after a field is touched, and blurred (focused out of), this is useful for text fields which might start out erronous but end up valid in the end (i.e. email, or zipcode). In these cases you don't want to rush to show the user a validation error message when they haven't had a chance to finish their entry.

Triggers error messages to show up as soon as a value of a field changes. Useful for when the user needs instant feedback from the form validation (i.e. password creation rules, non-text based inputs like select, or switches etc.)

Now, you feel a sudden urge to use it. You ping your team lead or send a message to your whole team about this cool new way of doing things, and you suggest that you start using it.

Hackathons are a great way of testing new technology with your team, and a place where you can go crazy with solutions.

The hype is something common in our industry. Remember NoSQL? Or when everyone went crazy over microservices? Or the AI / Machine learning burst? The list goes on and on. People get excited about new and breakthrough technologies and ideas.

The idea of having to learn something new is good, and I agree with that, but how often should you do that? Looking at the world of JavaScript, a new idea, blog post, library, framework, and whatnot pops up very often. Things become trending, and people quickly try to adopt that. I’m not saying you should not adopt new things and consider different approaches to a solution, not at all! I am trying to propose the idea of doing that less often.

Knowing all this, what would you do? Which path would you choose and why? The answer might seem obvious now that you come from the future - React