Personally, I'm starting to think that the feature where it automatically adds xray.js to the document is more trouble than it's worth. I propose that we remove that automatic feature and just make it part of the install instructions that you need to add this line to your template/layout: <%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %>

Now that I've thought more about it, I honestly think the auto-adding the script feature is overrated, over-complicated, and error-prone (#98, #100), and I propose we just remove it (#110).

now that I've thought more about it, I think the auto-adding the script feature is overrated, over-complicated, and error-prone (#100), and ought to just be removed (#110).

now that I realize how easy it is to just manually include this in my app: <%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %> I regret even wasting my time getting it to automatically look for and add a nonce to the auto-injected xray.js script

Source maps are a major new feature.

we’re going to look how improved pattern matching and rightward assignment make it possible to “destructure” hashes and arrays in Ruby 3—much like how you’d accomplish it in, say, JavaScript

Thanks, I'll continue leaning on the array workaround for my use case then.

So how are we going to create a model that doesn’t have a database table behind it? There are several potential solutions including various plugins but we’re going to use the method described in an entry on the Code Tunes blog. This shows a techinque that involves overriding a couple of methods in an ActiveRecord model and then manually defining the columns in the model file rather than in the database table. In our Recommendation model we’ll add in the two overridden methods and then use the column class method to define the columns in a similar way to how they’re defined in a migration file.

For now I feel ActiveForm is still a bit early to transition to a gem  as there are still things to improve and work out. One day I'll invest more time into making it extendable and release it as a gem. For now I feel it's an unnecessary complexity.

Writing the uniqueness validations yourself is easy so I felt it was better to leave this up to the developer

There is nothing wrong with accepts_nested_attributes_for. This is what you should use in your typical case. My post describes a non-typical case. ContactListForm is not an ActiveRecord object, it is an object that includes ActiveModel::Model, which does not support accepts_nested_attributes_for.

Report: This price didn't exist on the store This price did show on the store but the game could not be bought This was a very short price made by a mistake (glitch)

That ♡copyheart isn’t a legally binding license is not a bug – it’s a feature!

Adding backgrounds and borders does feel like a missing feature of the CSS Grid specification and one which the Working Group have discussed along with many members of the community (the discussion thread is on GitHub).

I hope we see new CSS capabilities arise that allow this sort of effect without the need for trickery.

Since CSS doesn’t (yet) offer a way to style grid cells, areas, or tracks directly, we have to stretch elements over the parts we want to style independently from the elements that contain content.

They likely won’t have any content, making them a sort of structural filler to spackle over the gaps in Grid’s capabilities.

proposes adding a grid-cell pseudo so you can add (responsive) decorative elements to grids without having to add empty elements to your page.

#grid::grid-area(1 / 2 / 3 / 4) { background-color: red;

The Gmail Android app that comes pre-installed with most new Android phones contains a feature to access non-Google accounts using POP and IMAP. Unfortunately, emails accessed through this setup lack the embedded style (<style>) support as well as the support for background images.

Great, I can use vw to scale text so it doesn't look puny on a desktop! Perfect... Oh. Huh, now the text is too small to read when viewed on a phone. Okay, well I can just use "max(x,y)" to make sure it doesn't get shrunk beyond a minimum size. Perfect... Oh. Hmm. Looks like "max" isn't supported properly by Chrome. Okay, well guess I'll just use "px" again.

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

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

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

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

Material Design guidelines don't specify popovers, but the specification of material properties provide a clear set of properties that can be used to create popups.

A hosted Kit is the easiest way to add Font Awesome to your website. It's a collection of icons, styles, and settings that allows you to make changes and update versions without pushing code.

It works very well, especially since the current Gimp roadmap relegates CMYK support to a version Gimp 3.2 However to be fairquoteShould a new developer join the team to specifically work on CMYK-related features, we will do our best to help him/her to complete this project and get it to our users as soon as possible.unquoteNot holding my breath.

I guess it's about "preloading" and not "navigation", if it's the case, then I guess there is still no way to attach to navigation events, and this issue should be kept open.

No JS event is fired, so there currently isn't any clean way to do this that I can see.

Press these buttons to move to the previous/next frame

No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

Yarn only runs the postinstall hook after yarn and yarn add, but not after yarn remove. The postinstall-postinstall package is used to make sure your postinstall hook gets executed even after a yarn remove.

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.

This creates an options object with a getter function for the passive property; the getter sets a flag, passiveSupported, to true if it gets called. That means that if the browser checks the value of the passive property on the options object, passiveSupported will be set to true; otherwise, it will remain false. We then call addEventListener() to set up a fake event handler, specifying those options, so that the options will be checked if the browser recognizes an object as the third parameter.

I also would like to see any hidden blocks or dev shortcuts.

I'm more bothered by the fact that you can't practice other people's levels, just certain parts of the level, before actually going back and trying to beat it completely.

You can also see this repo: default-passive-events.

Not being cancelable makes validating dialog content impossible - eg a login dialog or anything that takes user input. Of course, it's easy enough to get around - but I think this should be a requirement of a dialog.

It is impossible to rebuild the base from the Dockerfile as the 3rd party dependencies have changed significantly since 8 months ago when the base was last built. The tags for my base image have been overwritten and I can only restore them from a descendant image. With Docker 1.8 I simply pulled the descendant image, tagged the base layer and I was done. With Docker 1.10+ I'd need to save, then manually construct the base image descriptor and reload it. Doable but sad that it's far more complex.

Allowing parent layer metadata to be saved for a layer, regardless if the parent layer is in the save command, would be a huge win for those of us working on CI/remote systems. Reusing parent layers used to be ridiculously easy. It would be good if we could get some comparably easy way to do it now.

It used to be great that I was able to select a layer from any image and use it as a starting point. Currently, I am given an image that has 4 layers to be stripped off to get to the original base image. The original image is not reconstructable in any other way.

# Run once, hold otherwise if [ -f "already_ran" ]; then echo "Already ran the Entrypoint once. Holding indefinitely for debugging." cat fi touch already_ran

Edit this file (corresponding to your stopped container): vi /var/lib/docker/containers/923...4f6/config.json Change the "Path" parameter to point at your new command, e.g. /bin/bash. You may also set the "Args" parameter to pass arguments to the command. Restart the docker service (note this will stop all running containers):

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.

Directives like ng-if="info.report.revenue" sort of work in Angular if info.report is undefined, in that the ng-if becomes false. But the Svelte equivalent {#if info.report.revenue} throws an error. For now we're using lodash get in places where we need to and looking forward to Svelte support for optional chaining.

This is not an MDC Web component. It is an addition that SMUI provides.

That file is mandatory, but it can contain nothing, if you want the default theme.

In Angular CLI 6 this command has been removed, and it will not come back. Instead there is a new concept called Builders.With the new Angular CLI you can customize the build process by defining your own builders as well as using one of the builders provided by the community.

Since you've been using Svelte for a few months after using React, haven't you been hit by the lack of composability in Svelte?Passing around components as variables is such a common pattern in React, and there's no good replacement in Svelte. The lack of dynamism in components and styles makes theming and crafting reusable components (outside of simple widgets) very tedious [1][2]. I'm genuinely curious how someone can come from React and not be bothered by it.

If this is getting implemented, I think I'll love to see both implemented. I can see a lot of use cases where I would like to encapsulate the component with additional wrappers and in another scenarios I would like to just use the component. Now i work around this using empty div but then at times it breaks the structure because of the div element and I'll have to add more class utilities to make it work. This will be a great addition for Svelte.

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

I also tried to use <!-- svelte-ignore unused-export-let --> before the script tag but still no chance.

You can only adopt a workaround, which can be one of

Just coming here to voice my agreement that these warnings are annoying and exist in other libraries as well. For me this happened with svelma. I didn't write the library code, so I don't have complete control over it even though I agree there is an argument to be had around whether I should be notified anyway. In either case, these warnings should be easily disabled since libraries don't always get updated over night.

I use a mutator and use it's changeValue function to 'change' the value of the relevant field (I supply the same value). This in turn notifies all relevant parties of the change to the form's state, and a validation is triggered.

Use the same value that was submitted, which ensures that a 'change' is triggered even though the value itself doesn't change. Therefore, the same value gets validated again.

  mutateValue([name], state, { changeValue }) {
    // change the value to the same value, thus
    // triggering a revalidation of the same value
    changeValue(state, name, value => value);
  }

But it sounds like the library could use some way to setTouched()

I have a feature spec to test the Javascript behavior of the blur event, sadly Capybara's native DSL doesn't seem to support it yet.

Wondering how to get field state from multiple fields at once? People coming from Redux-Form might be wondering where the equivalent of Redux Form's Fields component is, as a way to get state from several fields at once. The answer is that it's not included in the library because it's so easy to write one recursively composing Field components together.

Perhaps we should detect URLSearchParams objects differently (using duck typing detection instead of instanceof window.URLSearchParams, for example) but the solution isn't adding a specific polyfill to Axios (as it'd increase the bundle size and still won't work with other polyfills).

Sometimes we can’t implement a solution that’s fully spec-compliant, and in those cases using a polyfill might be the wrong answer. A polyfill would translate into telling the rest of the codebase that it’s okay to use the feature, that it’ll work just like in modern browsers, but it might not in edge cases.

The intuition behind POJOs is that a POJO is an object that only contains data, as opposed to methods or internal state. Most JavaScript codebases consider objects created using curly braces {} to be POJOs. However, more strict codebases sometimes create POJOs by calling Object.create(null) to avoid inheriting from the built-in Object class.

This isn’t to say that multiplying code is good or bad – it’s a characteristic of all code regardless of quality.

What makes it good or bad is the quality of the code being multiplied.

Supporting JSX out of the box is the engineering equivalent of Mozilla supporting DRM out of the box in FireFox.

However, in function components there really isn't much need for this pattern since you can just use JS default arguments

We aim to support all svelte features. In some cases this is not possible. For those cases we provided feasible workarounds.

Balanced named tags is a critical syntactic feature of the XML-style notation.

A program somewhat controlling it's own flow. That's the key feature that makes a programming language Turing complete.

A programming language is Turing complete if you can implement any possible algorithm with it.

Moreover, React team even removed the “highlight updates” feature from dev tools because people used to obsessively haunt wasted renders with no reasoning behind it

I discovered that a solution can be hacked using an {#if}, but a proper one would be nice:

Here's a proxy store I wrote to derive the value of a store nested within other stores, it plays nice with typescript and can go infinitely deep

(Note sure if this is a feature request or a bug...)

But of course this could be overused.

<p>{(x *= 4)} {(x *= x)} {(x *= x)}</p>

This reactive statement is just used to have the store automatically subscribed and unsubscribed.

I'm suggesting there should be a way to write lifecycle related code that also responds to changing props, like how useEffect works. I think how React handles this could be a good source of inspiration.

One thing I considered was abusing a custom store for this kind of thing.

the code is a bit verbose/convoluted

Using another reactive statement with $effect we have Svelte automatically handle subscribing and unsubscribing to the store

Art by O’Hare and Bell highlight - both visually and conceptually - the dialogic quality of annotation expressing power.

Solid’s State primitive is arguably its most powerful and distinctive one. Through the use of proxies and explicit setters it gives the control of an immutable interface and the performance of a mutable one

Solid supports most React features like Fragments, Portals, Context, Suspense, Error Boundaries, Lazy Components, Async Rendering, Implicit Event Delegation, SSR

I guess we could always add a bunch of adapter code to watch the flag and trigger a callback when it becomes true or false...

but would it be reasonable to expect svelte-select to handle that so that consumers of this lib don't have to do all that?

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.

Vue does this in a way that just makes sense.

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.

It would be tiresome - and bloated - to include a class pass-through for every component or assigning custom properties (from the RFC linked) for all potential properties on every component, just in case it's gonna be used in layouts that requires it. Wrapping them in a wrapper div is certainly an option, but potentially creates 100s or 1000s (long lists, several lists etc.) of new elements in the DOM slowing down low-end devices.

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.

For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.

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

Allow creating custom components with the same abilities as native dom. By all means keep the same level of encapsulation, don't push class on components, but allow a component to mark the class property or another as a CSS Class property, in which case you could pass it through the same transformation that native elements go through

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.

Your tooltip component will have to wrap your image with a span tag or something, it can’t just add events to its children. And if you are adding multiple actions to it you will have to wrap it multiple times.

<Concern1> <Concern2> </Concern2> </Concern1>

vs.

<img use:concern1 use:concern2>

Lets not extend the framework with yet another syntax

and one which you don’t need to use and won’t add any code to your app if you choose not to use

And of course, if you don't use them you don't pay for them

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.

You can imagine the ensuing combinatorial explosion if we needed to add borders or box shadows or filters or what-have-you.

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.

Drag and drop might be done better with hooks than components.

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

The other possible route would depend on #640 (dynamic components), plus the ability to pass around element names as strings in place of components, plus #195 (spread).

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.