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.

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

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.

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.

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

Furthermore, incumbents who generally do a good job, often manage to continue reigning. According to Brad Gerstner, CEO of Altimeter Capital, who recently did a podcast on Invest Like The Best, large tech companies have managed to take even more market share than 10 years ago. Some people may argue this is because the large tech companies have improved their products over time to stay ahead due to their increased collection of data and better algorithms that feed on that data over time. That may be true for some companies but not all. This also applies to other products that have not made significant strides in their technology — Craigslist, Salesforce CRM, Turbotax, Quickbooks to name a few. Even Google Search which arguably had a better product in the 1990s compared to its peers is about on par with alternative search engines today, but 90% of people worldwide still use Google. Old habits die hard, and distribution matters more than ever if you are just starting a business. It’s hard to topple incumbents who have strong distribution and already large audiences — even if you can build a much better product.

We share our labor of love

FWIW, I would have raised it earlier if I thought it would have made a difference.

If we've gone more than a year without this being a problem in the slightest, I don't see how the next year would be any different.

Can't upvote this enough. It is highly irritating to see language destroyed (and we wonder why kids bastardize the language..).

As a web designer, I hate that "log in" creates a visual space between the words. If you line up "Log In Register" - is that three links or two? This creates a Gestalt problem, meaning you have to really fiddle with spacing to get the word groupings right, without using pipe characters.

I don't doubt that we will soon treat the process of logging in as a figurative point of entry, meaning that log into will make full conceptual sense (cf you don't physically delve into a problem or pile into an argument, yet both are correct grammatically because they are semantically [i.e. figuratively])

New information that would be useful toward the future usage or troubleshooting of GitLab should not be written directly in a forum or other messaging system, but added to a docs MR and then referenced, as described above.

When you encounter new information not available in GitLab’s documentation (for example, when working on a support case or testing a feature), your first step should be to create a merge request (MR) to add this information to the docs. You can then share the MR in order to communicate this information.

I really can't see how we can trust browsers accept headers. :'( More about the situation than about your statement.

I will have to look at code to be sure but the rule that */* trumps all is applied only when the request is not an ajax request. So if you are making ajax request then you should be good.

I could add .json on the end, but that would mean hacking away at angularjs, which is doing the right thing. I would rather find a good solution and hack away at rails, which is doing the wrong thing :)

In that case I would suggest to use .xml or .json format to eliminate accept header parsing issue.

Safari sends following order application/xml (q is 1) application/xhtml+xml (q is 1) image/png (q is 1) text/html (q is 0.9) text/plain (q is 0.8) \*/\* (q is 0.5) So you visit www.myappp.com in safari and if the app supports .xml then Rails should render .xml file. This is not what user wants to see. User wants to see .html page not .xml page.

Historically, it was defined as one minute (1/60 of a degree) of latitude along any line of longitude. Today the international nautical mile is defined as exactly 1852 metres (about 1.15 miles).

having a completely distributed team can make it very difficult for team members to get to know each other on a personal level

Course as community onboarding

As a result, I end up quoting multiple people, sometimes quoting several people back-to-back, before even writing my reply. In those instances it feels like I'm not properly citing those individuals. I feel like it might seem I'm not providing new readers appropriate context for a given quote. It might also be implied that separate quotes are from the same person, leading to mis-attribution.

As a later iteration, it might be cool to see a link between the quoted content and my comment

I went against the grain, applying other tools that people have written over the years to directly perform the job at hand which do not involve entering a program for awk or a shell to run, with answers like https://unix.stackexchange.com/a/574309/5132 and https://unix.stackexchange.com/a/578242/5132 . Others have done similar. https://unix.stackexchange.com/a/584274/5132 and https://unix.stackexchange.com/a/569600/5132 are (for examples) answers that show alternative tools to answers employing shell script and (yet again) awk programs, namely John A. Kunze's jot and rs (reshape), which have been around since 4.2BSD for goodness' sake!

"When an OP rejects your edit, please do not edit it back in!" Correspondingly, when a user repeatedly does try to edit, understand that something in your framing isn't working right, and you should reconsider it.

It reused many ideas and classes from Doug Lea's Collections package, which was deprecated as a result.

GTD strategies

In our series, learning linked data, we've covered several topics related to querying linked data using several SPARQL features and techniques, producing linked data using RDFa and working with JSON-LD.

Note that the point of JSON-LD is that it's just JSON, in this case using the schema.org context to interpret the values.

Even as machine-readable data begins to permeate the web, it is typically distributed in a separate file, with a separate format, and very limited correspondence between the human and machine versions.

But I'll definitely take underscore mixins over extending String.prototype or other clunky implementations any day.