385 Matching Annotations
  1. Last 7 days
    1. Really? I've been using Flutter for about a week and Svelte seems an order of magnitude better designed. I find Flutter overly complicated.
    2. Svelte by itself is great, but doing a complete PWA (with service workers, etc) that runs and scales on multiple devices with high quality app-like UI controls quickly gets complex. Flutter just provides much better tooling for that out of the box IMO. You are not molding a website into an app, you are just building an app. If I was building a relatively simple web app that is only meant to run on the web, then I might still prefer Svelte in some cases.
    1. If I understand the problem correctly, just changing the imports to point to svelte/internal isn't enough because they could still point to different packages depending on how your components are bundled. It solved your specific issue, but if you had two completely unrelated Svelte components compiled to vanilla javascript bundled with Svelte, you'd still hit issues with mismatching current_component when using slots or callbacks.
    2. It sounds like another case of multiple svelte/internal modules? I think we need to look into reworking how svelte/internal keeps track of the current component since it breaks when mixing components not bundled with the app. It sounds like we need to find a way to pass Svelte's internal runtime state when instantiating components, since slots and callbacks end up mixing different svelte/internal together.
    1. As mentioned in #2937, this is the sort of thing that happens when you have two copies of Svelte's internal scheduler running. If you're importing the compiled version of an external Svelte component into another Svelte component, this is what you end up with. There's a svelte field in package.json that's respected by rollup-plugin-svelte and which is intended to point at the uncompiled Svelte source, so that the external component can be bundled together with the main app, without any duplicated internals.
    2. DOM element binding using the bind:this attribute doesn't work apparently
    1. In the past, I tried to create some proof of concepts with svelte, but I usually ended up missing some of the features that RxJS provides. Now that I know that they complement each other well, I will grab this combination more often
    2. For me, this makes Svelte the most reactive "framework" at the moment
    1. Because of those similarities, it's possible to automate some of the changes.
    2. Those frameworks are used in a similar fashion, but conceptually use quite different approaches (Vue is a more traditional one, a library, and Svelte is a "dissapearing framework").

      interesting wording: Svelte is a "disappearing framework".

  2. Nov 2020
      • Functional blockchain library in Typescript
      • Svelte & Sapper for all things UI.
      • Blockchain sync with IndexedDB and reactivity hook.
      • Created some mini-apps to refine and test the core functionality.
      • User Authentication flow.
      • MVP: Kanban app.
    1. I encounter this problem in all of my Svelte projects- feels like I'm missing something. Fighting it with absolute positioning usually forces me to re-write a lot of CSS multiple times. Is there is a better way to solve this that I've overlooked?
    1. Svelte's advantage here is that it indicates the need for an update at the place where the associated data is updated, instead of at each place the data is used. Then each template expression of reactive statement is able to check very quickly if it needs to rerender or not.
    2. Converting Angular components into Svelte is largely a mechanical process. For the most part, each Angular template feature has a direct corollary in Svelte. Some things are simpler and some are more complex but overall it's pretty easy to do.
    3. We don't use "attribute directives" much which makes things easier.
    4. 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.
    5. Embedding Svelte inside Angular is pretty easy, for the most part. I wrote a function that would take in a Svelte component and generate an Angular controller class.
    6. It's really helpful that Svelte stores are easy to use in plain JS. We can change a state store over completely to Svelte and make the Angular components subscribe to that store as well without needing to maintain and sync 2 copies of the state.
    7. Svelte slots are much easier to use and reason about than Angular transclude, especially in cases where you don't want an extra wrapper element around the slot content.
    1. Any “unused” css will be stripped out when compiling, and since the compiler correctly sees that we have no p tags in App.svelte , it throws out that bit of css.
    1. After a few hours experimenting (updated NPM, NODE, ...) I found that renaming _smui-theme.scss to smui-theme.scss (without underscore prefix) solved the problem. I don't understand the mechanics behind (why in documentation is file with prefix).
    1. If your Svelte components contain <style> tags, by default the compiler will add JavaScript that injects those styles into the page when the component is rendered. That's not ideal, because it adds weight to your JavaScript, prevents styles from being fetched in parallel with your code, and can even cause CSP violations. A better option is to extract the CSS into a separate file. Using the emitCss option as shown below would cause a virtual CSS file to be emitted for each Svelte component. The resulting file is then imported by the component, thus following the standard Webpack compilation flow.
    2. If you rely on any external dependencies (files required in a preprocessor for example) you might want to watch these files for changes and re-run svelte compile. Webpack allows loader dependencies to trigger a recompile. svelte-loader exposes this API via options.externalDependencies.
    1. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.
    2. 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.
    3. I don't love that you have to re-assign a object/array variable to get Svelte to notice it changed
    4. Stores are such an amazing abstraction.
    1. 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

    1. This subscription function must be immediately and synchronously called with the store's current value upon calling .subscribe. All of a store's active subscription functions must later be synchronously called whenever the store's value changes.
    2. Assignments to $-prefixed variables require that the variable be a writable store, and will result in a call to the store's .set method.
    1. What bothers me most from Svelte: <!-- I want to bind the value of this custom input just like I would bind to normal input --> <input bind:value="query" /> <!-- works --> <search-input bind:value="query" /> <!-- doesn't work :/ -->

      I think this works in current Svelte

    2. Essentially, for version 2 I'd like to move away from the Mustache-esque template syntax to something a bit lighter and more modern, which boils down to using one curly brace instead of two:
    3. The success of JSX has proved that the second curly is unnecessary. Moreover, a lot of people — particularly those who have been exposed to React — have a visceral negative reaction to double curlies, many of them assuming that it brings with it all the limitations of crusty old languages like Mustache and Handlebars, where you can't use arbitrary JavaScript in expressions.
    1. <input {...omitBy({pattern: undefined}, isUndefined)}>
    2. For now, using spread attributes allows you to control which attributes appear on an element. <div {...foo}> where foo is an object of attribute keys and values will add/remove attributes according to which are present and non-null.
  3. Oct 2020
    1. My version of https://svelte.dev/repl/9c7d12357a15457bb914705702f156d1?version=3.19.2 from https://github.com/sveltejs/svelte/issues/4586

      to try to simplify and help me understand it better.

      So the lack of synchronousness is only noticed inside handleClick.

      By the time the DOM gets updated, it has a consistent/correct state.

      In other words, the console.log shows wrong value, but template shows correct value. So this might not be an actual problem for many/most use cases.

    1. I too have been confused by behavior like this. Perhaps a clearly defined way to isolate atomic units with synchronous reactivity would help those of us still working through the idiosyncrasies of reactivity.
    2. For performance reasons, $: reactive blocks are batched up and run in the next microtask. This is the expected behavior. This is one of the things that we should talk about when we figure out how and where we want to have a section in the docs that goes into more details about reactivity. If you want something that updates synchronously and depends on another value, you can use a derived store:
    1. I don't want Svelte to go out of its way to try to catch all these edge cases. It would require lots of fragile heuristics in the compiler. I want a solid compiler I can trust, not something magic but often out of service. I want it the simplest possible.
    2. There's an issue #3368 for describing better what triggers reactive updates, as I do think there is some stuff we could be more explicit about
    1. Presumably this is so that you can import React libraries, even if they depend on ReactDOM, and they will work with Svelte instead.

      Reminds me of Wine. IIRC they have some system calls that they just make to be no-ops on Linux.

    1. Indeed, it looks like svelte-hooks did add support for clean-up functions to their useEffect in devongovett/svelte-hooks@1d39d95! ... which is great, though @DylanVann's much simpler and zero-dependency version is even better in some ways.
    2. I think Svelte has some things to learn from React hooks.
    3. While react hooks were one of the catalysts for v3 we don't agree with with the APIs or the model and won't be emulating it.
    4. One thing I considered was abusing a custom store for this kind of thing.
    5. Store is reactive because it should re-evaluate when track is changed.
    1. Svelte forces you do to do all kinds of things in a very specific way (as does every other framework/library), those constraints generally make for a better experience.
    2. This is basically a design goal at this point, even though it has evolved organically.
    3. One of Svelte's advantages, for me, is that I can test out ideas with relatively few lines of code. the #with feature could save me from adding a separate component for the content of an #each loop. I get frustrated when I have to create a new file, move the content of the #each clause, import it as a component, and add attributes and create exports for that, and implement events to send messages back, and event handlers, when I just wanted to test a small feature.
    4. my second preference would be for let, probably #let expr as name for consistency with #each.
    1. You can see that behaviour in this example. Select a range of text and hit the tab key. Because the <textarea> value changes, the current selection is cleared and the cursor jumps, annoyingly, to the end.
    1. const { getByRole } = render(<input bind_value={text}>)
    2. svelte-htm - Hyperscript Tagged Markup for svelte; a jsx-like syntax using Tagged Templates
    3. For the sake of best compatibility we convert the className attribute to class for svelte.

      Svelte refuses to standardize on any way to pass a CSS class. I thought className was actually the most common name for this prop though even in Svelte...

    4. For event listeners we support the standard jsx naming convention onEventname (this is converted to on:eventname in svelte) as well.
    1. This is a very simple task for React and literally impossible for Svelte.
    2. It adds a few constructs to the language to solve one of the most complex problems in UI development — state management.
    3. The official Svelte blog, on the contrary, ends up mind tricking the reader by showing only one side of the coin, sometimes through upfront false statements about web technologies and other libs
    1. As we've briefly seen already, you can listen to any event on an element with the on: directive:
    1. A reasonably clean alternative would be to map a function over the array and use destructuring in the each loop: {#each [1, 2, 3, 4].map(n => ({ n, sqr_n: n * n })) as { n, sqr_n }} {sqr_n} {sqr_n / 2}<br> {/each}
    2. Could I get your intuition for why that rule of thumb applies to svelte components but not Javascript functions? I tend to make heavy use of let x = e when writing normal Javascript, as I do in most other languages (though unlambda is a notable exception). How is svelte different?
    1. Unlike DOM events, component events don't bubble. If you want to listen to an event on some deeply nested component, the intermediate components must forward
    1. About the argument against it, "{@const will make code less consistent ": I think the same is true now, since people can come up with very different ways of dealing with the "computed value inside each loop/if function" problem. Some extract components, some use functions, some will prepare the array differently beforehand.
    2. Do these blocks allow for reactive assignments? @lukeed They're read-only, but values update when their dependencies do
    1. Generally, you should read the value of a store by subscribing to it and using the value as it changes over time. Occasionally, you may need to retrieve the value of a store to which you're not subscribed. get allows you to do so.