20 Matching Annotations
  1. May 2021
  2. Mar 2021
  3. Feb 2021
  4. Dec 2020
    1. This is the accepted way to handle problems related to authentication, because user data has a couple of important characteristics: You really don't want to accidentally leak it between two sessions on the same server, and generating the store on a per-request basis makes that very unlikely It's often used in lots of different places in your app, so a global store makes sense.
    2. But Svelte 3 doesn't have global stores that are passed around in quite the same way.
    3. Just realised this doesn't actually work. If store is just something exported by the app, there's no way to prevent leakage. Instead, it needs to be tied to rendering, which means we need to use the context API. Sapper needs to provide a top level component that sets the store as context for the rest of the app. You would therefore only be able to access it during initialisation, which means you couldn't do it inside a setTimeout and get someone else's session by accident:
  5. Nov 2020
  6. Oct 2020
    1. All containers without a --network specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate.
    1. In a browser, deep-diff defines a global variable DeepDiff. If there is a conflict in the global namespace you can restore the conflicting definition and assign deep-diff to another variable like this: var deep = DeepDiff.noConflict();.
    1. Polyfills are naughty as they patch native APIs, while ponyfills are pure and don't affect the environment.
    2. How are ponyfills better than polyfills? A polyfill is code that adds missing functionality by monkey patching an API. Unfortunately, it usually globally patches built-ins, which affects all code running in the environment. This is especially problematic when a polyfill is not fully spec compliant (which in some cases is impossible), as it could cause very hard to debug bugs and inconsistencies. Or when the spec for a new feature changes and your code depends on behavior that a module somewhere else in the dependency tree polyfills differently. In general, you should not modify API's you don't own.
  7. Sep 2020
    1. It relies on something that is inherently global. Different components might 'claim' a given property name. While it's possible to differentiate them at the subtree level, it's not possible to do so globally.
    2. This has all of the downsides of global CSS (except being able to style different instances of a component differently) plus more: it may result in the need for additional DOM, and... it's kinda ugly. It feels like a hack.
    1. Global selectors, even when scoped to a subtree, cascade just like regular CSS would. This might be fine for a leaf component, but anywhere else in your app, this is the CSS equivalent of crossing your fingers and hoping that bad things won't happen.
    1. It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.
    1. In mapbox.js you'll see this line: const key = {};We can use anything as a key — we could do setContext('mapbox', ...) for example. The downside of using a string is that different component libraries might accidentally use the same one; using an object literal means the keys are guaranteed not to conflict in any circumstance (since an object only has referential equality to itself, i.e. {} !== {} whereas "x" === "x"), even when you have multiple different contexts operating across many component layers.