Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:39
    RyanCavanaugh assigned #35559
  • 18:39
    RyanCavanaugh labeled #35559
  • 18:38
    RyanCavanaugh closed #35569
  • 18:38
    RyanCavanaugh labeled #35569
  • 18:38
    RyanCavanaugh unlabeled #35569
  • 18:38
    RyanCavanaugh labeled #35569
  • 18:37
    RyanCavanaugh labeled #35569
  • 18:37
    RyanCavanaugh labeled #35566
  • 18:36
    RyanCavanaugh labeled #35567
  • 18:34
    RyanCavanaugh milestoned #35557
  • 18:34
    RyanCavanaugh labeled #35557
  • 18:34
    andrewbranch synchronize #15575
  • 18:34
    andrewbranch synchronize #28460
  • 18:34
    andrewbranch synchronize #31641
  • 18:33

    andrewbranch on master

    Sort extract constant above ext… (compare)

  • 18:33
    andrewbranch closed #35580
  • 18:33
    andrewbranch closed #29589
  • 18:32
    RyanCavanaugh closed #35542
  • 18:31
    RyanCavanaugh labeled #35542
  • 18:30
    RyanCavanaugh closed #35543
Bruce Pascoe
@fatcerberus
The main advantage is you can use the value of a promise at expression-level
Whereas with .then() it’s just one step above callback hell
But other than that it's still just vanilla promise semantics under the hood, right down to the duck-typed .then
The best way to describe it is to imagine the async function is a generator, and await does something like Promise.then(x => currentGenerator.next(x)); yield;
Bruce Pascoe
@fatcerberus
Destructuring in function parameter lists still confuses the hell out of me: microsoft/TypeScript#33474
I look at the signature and it's like... okay... now exactly what am I supposed to provide at the callsite for that
I have to mentally reconstruct the destructuring in order to know what to pass to it
AnyhowStep
@AnyhowStep
Fuck that mess lol
Bruce Pascoe
@fatcerberus
I don't see how using the nightly helps, nightlies don't include unmerged PR features do they?
Bruce Pascoe
@fatcerberus
https://github.com/microsoft/TypeScript/issues/33475#issuecomment-532443362 - writing this up made me realize that classes should really always be nominally typed (even if there are no private properties) because of instanceof
obj instanceof B doesn't imply obj instanceof C at runtime
Guess that horse left the barn a long time ago though
Austin Cummings
@austincummings
@fatcerberus I thought the same thing when I was working on microsoft/TypeScript#32774.
Austin Cummings
@austincummings
...WRT nominal classes and instanceof
Shanon Jackson
@ShanonJackson
without providing any examples i feel like that would break interface same-name-as-class extension types
AnyhowStep
@AnyhowStep
One potential problem I might have with that narrowing is that it's possible to have A|B and then fail the A test and have it narrowed to B, even though it isn't B because it structurally matches A, just doesn't have the right prototype
@austincummings does your PR address that? =x
Like, if it fails the A constructor test, it shouldn't narrow in the false branch. Should still be of type A|B, imo
Because it looks like that test rules out the nominal side but not the structural side
Bruce Pascoe
@fatcerberus
Does instanceof behave that way now?
Because his test is basically just a different way to do an instanceof check
AnyhowStep
@AnyhowStep
class A {
  x! : number
}
class B {
  y! : number
}

//Neither A nor B, nominally
//Is A, structurally
const aOrB : A|B = { x : 32 };

if (aOrB instanceof A) {
  const a : A = aOrB; //OK
} else {
  const b : B = aOrB; //Expected to fail; is OK
}
Bruce Pascoe
@fatcerberus
So instanceof does narrow in the false branch
AnyhowStep
@AnyhowStep
I wonder if there's an issue
Asking to "fix" this
I could find anything
I used "instanceof narrow false branch"
Bruce Pascoe
@fatcerberus
Definitely think classes should have been all nominal all the time, but I'm realistic and realize that's not possible to change now
Plus it would differentiate class from interface typing-wise
AnyhowStep
@AnyhowStep
I guess I'll open an issue and wait for it to be closed as duplicate or working as intended lol
Bruce Pascoe
@fatcerberus
Haha
AnyhowStep
@AnyhowStep
AnyhowStep
@AnyhowStep
image.png
There are way too many ways to fetch a value from a database >.>
fetch-all-unmapped is the base "fetch" function and everything else is just a convenience function
AnyhowStep
@AnyhowStep
I haven't even worked on pagination and cursors yet
Shanon Jackson
@ShanonJackson
why not just...
import * from "./fetch"
fetch.mapped
fetch.unmapped
fetch.one
AnyhowStep
@AnyhowStep
I put every function in a separate file
Because each function can easily be hundreds of lines long. Not these ones. But I like consistency
Shanon Jackson
@ShanonJackson
i can see that
compose :)
AnyhowStep
@AnyhowStep
These functions aren't meant to be used externally
myQuery.fetchXxx()
Is how it would be exposed.
I have functional APIs internally but expose a fluent API for the most part for query building
Shanon Jackson
@ShanonJackson
fetch = {
mapped(...args: typeof fetch-mapped): ReturnType<typeof fetch-mapped> {
return mapped(...args); or whatever
}
}