228 Matching Annotations
  1. Last 7 days
    1. 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="..."/>.
  2. Jan 2021
    1. 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
    1. https://github.com/sveltejs/svelte/issues/1037#issuecomment-737872461

      Explanation (from https://github.com/sveltejs/svelte/issues/1037#issuecomment-739458005):

      @AlexGalays register is an action created and passed in from the parent node (Wrapper) which allows the child to register with it. Not builtin to svelte.

      That's very clever @PatrickG. Nice one. I was a bit confused when first looking at it to understand what was going on, but I think that will be a handy tool in the toolbox.

      But why do we need this? If we remove all use:register, it still toggles just fine. Seems the only benefit is that this allows cleanup.

    1. 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.
    1. 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.
  3. Dec 2020
    1. 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.
    1. 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.
    2. No JS event is fired, so there currently isn't any clean way to do this that I can see.
    1. 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.

      This could be both good and bad.

      potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.

      Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.

      Ah, good, I see they touched on some of these points in the sections:

      • Benefits of patching over forking
      • When to fork instead
    2. 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.
    1. 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.
    1. 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.
    1. I also would like to see any hidden blocks or dev shortcuts.
    2. 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.
  4. Nov 2020
    1. 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.
    2. 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.
    3. 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.
    1. # Run once, hold otherwise if [ -f "already_ran" ]; then echo "Already ran the Entrypoint once. Holding indefinitely for debugging." cat fi touch already_ran
    2. 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):
    1. 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.
    1. 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.
    1. That file is mandatory, but it can contain nothing, if you want the default theme.

      Optional but still kind of mandatory. Odd.

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

      Why did they remove it if it was useful? They wanted people to be stuck in Angular CLI world? Couldn't they still provide that escape route / migration path for those that really do need/want to eject?

    1. 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.
    1. 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.
    2. 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 like it

  5. Oct 2020
    1. 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.

      Calling it "change" even though it didn't change is kind of cheating/abuse ... but I guess it's okay...??

        mutateValue([name], state, { changeValue }) {
          // change the value to the same value, thus
          // triggering a revalidation of the same value
          changeValue(state, name, value => value);
        }
      
    1. 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).
    1. 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.
    1. 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.
    1. Art by O’Hare and Bell highlight - both visually and conceptually - the dialogic quality of annotation expressing power.

      While I'm reading this, I can't help but wishing that Hypothes.is would add a redaction functionality to their product. They could potentially effect it by using the highlighter functionality, but changing the CSS to have the color shown be the same as that of the (body) text instead of being yellow.

    1. Solid supports most React features like Fragments, Portals, Context, Suspense, Error Boundaries, Lazy Components, Async Rendering, Implicit Event Delegation, SSR
  6. Sep 2020
    1. 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...
    2. 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?
    1. 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.
    2. Vue does this in a way that just makes sense.
    3. 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.
    1. 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.
    2. 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.
    3. 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.
    1. There's no way to change style incapsulation method without patching the compiler, and this means maintaing a fork, which is not desirable.
    2. 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
    1. And of course, if you don't use them you don't pay for them
    2. Why not just do something like this?
    3. 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.
    4. 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.
    5. You can imagine the ensuing combinatorial explosion if we needed to add borders or box shadows or filters or what-have-you.
    6. I'm just pushing on the "is this really a good idea" front
    7. 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.
    8. 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.)
    9. 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.
    10. Drag and drop might be done better with hooks than components.
    11. This can and should be done with other components, IMHO.
    12. 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).
    13. 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.
    1. CSS encapsulation is a critical feature of single file components in Svelte; it allows you to think only about the styles that live together in a given component. Managing CSS has long been one of the more challenging aspects of building for the web; we have no desire to bring those problems back via official APIs that encourage the de-scoping of CSS. We do not wish to revisit the age of namespaced CSS selectors and required preprocessors.
    2. I understand what you're getting at, but we shouldn't miss out on useful features just because a few developers will abuse it...
    1. And normally, accepting a class prop is documented in the component's props, so passing a class prop to a component that doesn't utilize it, and see no effect is not surprising at all, in the sense that passing any undocumented prop normally mean that it will have no effect.
    2. The nice thing with this implementation is that it doesn't have any overhead or modified behavior for code that doesn't use the feature. If you don't like, no harm done, you can just ignore it.
    1. Syntax-wise, I would like to be able to pass id, style and class DOM attributes as well as (ideally) svelte props to whatever the slot was replaced with, so prefixing everything with attr in the slot that should be passed sounds like a good idea. Examples: <slot attr:class=“test” attr:class:active={true} /> or <slot attr:style=“color: red” attr:id=“henlo” />
    1. If your reaction to the video was 'fine, but if we use TypeScript and write plugins for each editor then we can get all the autocomplete and syntax highlighting stuff' — in other words, if you believe that in order to achieve parity with CSS it makes sense to build, document, promote and maintain a fleet of ancillary projects — then, well, you and I may never see eye to eye!
    1. Secure-by-default is a great approach, but this is not that. It's not even, we know what's best. It's clean up your act or you're out. You really should provide an opt-in to running with scissors. Maybe like config.opt_in_to_dynamic_routes_you_dumbass = true. 1 Pick your reaction
    2. I too would like to know more about the security concerns that are the motivation to remove these useful dynamic routing components. The only thing I can think off is someone who accidentally exposes a private method public, is there more? The dynamic routes are a great way to keep the routing.rb DRY and avoid unneeded dependencies between the routing and the controller files, it has been quintessential Rails magic since version 1.0, surely there must be more serious security concerns to give up such important benefits? What are they? Do we really need to completely remove this from the code base, when removing it from the default routes.rb already would get you most of the security benefit?
    3. I'm sure the security overlords have our best interest in mind and I'd be happy to change my opinion if someone can explain this tradeoff better. I know I can recreate the functionality for myself but I also like to keep in mind what's best for Rails. Just a hand wavy "we've had this for almost 10 years, but it might become an issue in the future so let's preventively eliminate it" does not seem a good enough reason to cut a feature that can make code much more DRY and elegant.
  7. Aug 2020
    1. 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.
    1. What is Search, Anyway?Steam Search does more than just looking up games; it's a powerful tool that drives many of our discoverability features, including Top Sellers and Specials pages. Today's features are available anywhere the Search tool is used across the store.
  8. Jul 2020