20 Matching Annotations
  1. Nov 2021
  2. Sep 2021
    1. Which do you prefer? If the answer was "the first" then read no further. You have all you need, go forth and be happy.

      good example of: not just assuming people are dissatisfied / will want to change

    1. Saying that web devs used to be fine with relative imports is like saying that human beings used to be fine living without refrigerators. Sure we did. But was it better than it is now? No. No, it wasn't.
    2. Aliases are absolute nonsense for resolving imports. If you don't want to type ../ consider using something like path.resolve(__dirname, '../src') so you can do import Stuff from 'client/components/stuff'; // relative to root of project instead of: import Stuff from 'COMPONENTS/stuff'; // this is dumb
    1. Yeah I don’t think we will find something that works for everyone in all cases. But Webpacker is quite flexible with the setup it has now. Easy to change!
    2. I feel like app/packs (or something like it) is a good name because it communicates to developers that it's not just JavaScript that can be bundled, it's also CSS, images, SVGs — you name it. I realize what can be bundled is wholly dependent on the bundler you use, but even esbuild supports bundling CSS. So couldn't this possibly be confusing?
    1. Some would argue that the phrase ''survival of the fittest'' is tautological, in that the fittest are defined as those that survive to reproduce.
  3. May 2021
  4. Apr 2021
    1. Games that aren't really like rogue, but tagged roguelike. Lite on rogue elements, they should be tagged as roguelite or genre_roguelike instead. For more info, check out: http://en.wikipedia.org/wiki/Roguelike
  5. Feb 2021
  6. Jan 2021
    1. In my opinion, it can sometimes look odd. Very interestingly, this is by design and is part of the Material design specification. This article isn’t to argue whether it should be this way or not, though; it’s just to change yours such that your MenuItem(s) show below the menu selection, like so:
  7. Sep 2020
    1. Actually just returning the loginDaoCall works fine. I dont really get what's different as it is the looked like it was the same instance, but probably not.

      So the posted answer wasn't necessary/correct? Which part of the answer was incorrect/unneeded?

      I wish this OP comment included the full version of code that worked.

      I don't understand this OP comment. Wasn't OP already returning loginDaoCall? So maybe the only thing they could mean is that they just needed to change it to return loginDaoCall.then(...) instead...

      That would be consistent with what the answer said:

      the promise returned by the further .then() does also get rejected and was not handled.

      So I guess the unnecessary part of the answer was adding the return true/false...

    1. This is a framework and it comes with certain opinions about how things should be done, this isn't unique to Svelte. And before we can decide whether or not we will allow certain behaviour or encourage it with better ergonomics, we have to have a conversation about whether or not we should be doing things that way. You can't separate the can from the should in an opinionated framework. We want to make building UIs simpler, for sure, but also safer we don't want to add ease of use at the expense of component encapsulation, there has to be a balance
  8. May 2020
  9. Apr 2020
    1. For instance, if an IP address is sent with an ad request (which will be the case with almost any ad request as a consequence of internet protocols), that transmission will not breach any prohibition on sending PII to Google.
    2. Google interprets PII to exclude, for example: pseudonymous cookie IDs pseudonymous advertising IDs IP addresses
    3. data excluded from Google's interpretation of PII may still be considered personal data under the GDPR