375 Matching Annotations
  1. Last 7 days
    1. Popper for Svelte with actions, no wrapper components or component bindings required! Other Popper libraries for Svelte (including the official @popperjs/svelte library) use a wrapper component that takes the required DOM elements as props. Not only does this require multiple bind:this, you also have to pollute your script tag with multiple DOM references. We can do better with Svelte actions!
  2. Dec 2020
    1. Biosciences Robert Sabin 713-348-4324 Charles Stewart

      library contact person

    1. Sometimes, systems just scale the problemA UI design system is more than the code of a component library. It’s more than the colors, styles, and margins of your elements. It’s an ever-growing and ever-evolving creature that entails your brand and your user’s feelings.

      If you don't understand the problem - you can [[scale the problem instead of solve the problem]], and it's important to remember that a [[design system is more than a component library]]

  3. Nov 2020
    1. This module should not be used in other npm modules since it modifies the default require behavior! It is designed to be used for development of final projects i.e. web-sites, applications etc.
    1. Is there any service that does this sort of alert when my library gets a book I want?

      Not quite the functionality you're looking for, but in the same sort of vein as WorldCat:

      Library Extension is a browser extension that works on Amazon, Goodreads (and possibly other book sites) that allows you to register your favorite local libraries, and when you look up books on those services, it automatically searches and shows you which are available at your local library. One click and you can usually download or reserve a copy quickly for pick up.

    1. The resolve.alias option is used to make sure that only one copy of the Svelte runtime is bundled in the app, even if you are npm linking in dependencies with their own copy of the svelte package. Having multiple copies of the internal scheduler in an app, besides being inefficient, can also cause various problems.
  4. Oct 2020
    1. Focus on your application: forget about forms details like I'm dirty, field touched...
    2. Form Validation
    3. return { type: "COUNTRY_BLACK_LIST", succeeded, message: succeeded ? "" : "This country is not available" }
    4. It is easily extensible (already implemented Final Form and Formik plugin extensions).
    5. You can try to build a solution to tackle these issues on your own, but it will cost you time and money... why not use a battle-tested solution to handle all this complexity?
    6. If you want to implement a form with a superb User Experience, you have to take care of many variables:
    7. Form validation can get complex (synchronous validations, asynchronous validations, record validations, field validations, internationalization, schemas definitions...). To cope with these challenges we will leverage this into Fonk and Fonk Final Form adaptor for a React Final Form seamless integration.
    8. Managing Form State (holding field information, check if a control has been touched, if the user has clicked the submit button, who owns the current focus...) can be tedious and prone to errors. We can get help from React Final Form to handle these challenges for us.
    1. 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.
    2. Svelte right now has a lot of opportunities to have component state become out of sync with props.
    3. I'm suggesting this is a problem generally. Users will not think of being out of sync with props
    4. Svelte doesn't re-render, so you need to respond to component mount/dismount and prop changes separately as they are distinct concepts and never tied together, unlike in React.
    1. A JavaScript DOM model supporting element creation, diff computation and patch operations for efficient re-rendering
    2. virtual-dom exposes a set of objects designed for representing DOM nodes. A "Document Object Model Model" might seem like a strange term, but it is exactly that. It's a native JavaScript tree structure that represents a native DOM node tree.
    3. virtual-dom is a collection of modules designed to provide a declarative way of representing the DOM for your app. So instead of updating the DOM when your application state changes, you simply create a virtual tree or VTree, which looks like the DOM state that you want. virtual-dom will then figure out how to make the DOM look like this efficiently without recreating all of the DOM nodes.
    1. While you could use a map function for loops they aren't optimized.
    2. Solid supports spread operator on native elements and Components.
    3. In general it is recommended you handle forms in this "controlled" manner. In some cases it might make sense to manage the form state outside of Solid via refs. These "uncontrolled" forms can also work. Just be conscious of the difference as mixing approaches can lead to unexpected results.
    1. Wait what? No runtime. How does that work? Well, obviously JavaScript executes at runtime, so was he saying he doesn't reuse any code? Well as it turns out the message here has changed. I looked and sure enough there was a runtime. Of course there was.
    1. A library is a set of functions you can use in your project. It does not care how and where you use that functionality. A framework tells you how to write code with the framework you are working with so you can make the best use of patterns, architecture, and functions in a framework. A framework can encompass a library.
  5. Sep 2020
    1. Rollup builds atop Browserify and Webpack's lineage to make it possible to easily consume those packages, while looking to the future of JS modules.
    2. When you publish this module, you do not want to bundle React, for the reasons described above. (It would be even worse to bundle React in a library, because then its copy would duplicate that loaded by the application!) But the fix is slightly different for a library than an application. In this library's Rollup configuration, we only want to specify external, not globals:
    1. As you've probably already figured out it's the last output definition that should be by legacy apps. With the above output configuration we allow consuming the component both from a modern app with a Node.js-based environment and from legacy apps.
    1. I don't understand why it just launches the mutation once and then it throws the error Function called outside component initialization, the only way to make it work is to do something like $: result = mutation(...) but it doesn't make sense, I don't want to run the mutation after each keystroke.
    2. We’re still working on idiomatic Svelte APIs so this one’s also on our list to figure out what the best way forward is
    3. For context, the previous API had a lazy promise. Currently I’m thinking we could just return a closure like in the React API
    1. urql/packages/svelte-urql/ Go to file Add file Go to file Create new file Upload files urql/packages/svelte-urql/
    1. I assume that soon developers will publish more components for svelte, and any possible class conflict is problematic. Yeah, it's rare case, but it is.
    1. 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.
    2. The main rationale for this PR is that, in my hones opinion, Svelte needs a way to support style overrides in an intuitive and close to plain HTML/CSS way. What I regard as intuitive is: Looking at how customizing of styles is being done when applying a typical CSS component framework, and making that possible with Svelte.
    3. 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.
    4. The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
    1. 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.
    2. 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.
    1. Does it look like a decorator plugin in Ractive, right
    2. 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.
    3. 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.
    4. Actions add additional functionality to elements within your component's template that may be difficult to add with other mechanisms. Examples of functionality which actions makes trivial to attach are:
    1. 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!)
    1. Extend ActionConfig interface in rfc-extended.d.ts file with new params: import * as RFC from 'react-fetching-library'; declare module 'react-fetching-library' { export interface ActionConfig { // Only new params skipAuth: boolean; params: any; }; }
  6. Aug 2020
    1. 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
  7. Jul 2020
  8. Jun 2020
  9. May 2020