This SO answer provides a typing for Object.assign that appears to
basically do the right thing: https://stackoverflow.com/a/51603499 -- but
none of the above libraries use this kind of solution, which leads me to
think it might not be totally robust
On Wed, Nov 11, 2020 at 1:27 PM Jordan Harband
I'd find it more readable to allow an assignment operator, with the
semantic "do this transformation, using the passed value as the previous
value"
```
function (x ??= 123) {} // If passed null or undefined, x = 123
function (x &&= 123) {} // If passed a truthy value, x = 123
function (x += 123)
For what it's worth, TypeScript has Enums built-in and I find myself using
string literal types instead:
```typescript
type CollisionType = 'CIRCLE' | 'CUBIC_BEZIER_CURVE' | 'RIGID_BODY';
function handleCollision(type: CollisionType) {
if (type === 'CIRCLE') {
// ...
} else if (type ===
> This feels like rich territory for a blog post, if someone feels
qualified? Specifically, just running the typescript tool chain for jsdoc
annotations, which are excellent for all the reasons mentioned above
(comments only, vanilla js etc).
Does this count?
Reading through the issue JoePea linked to, it looks like the difficulties
with standardized async stack traces are twofold:
1. Even with the error stacks proposal, the implementer has total say over
what qualifies as a stack frame
2. The way promises are chained means that some patterns like
at 8:08 PM Jacob Bloom
wrote:
> Is the Perl syntax opt-in like the proposed operator? Or does it happen on
> all accesses to nulls? If it's opt-in in JS, then it doesn't seem to me
> that it'd cause too much unexpected behavior, though it could be argued
> that it's ripe for abuse by ne
as on more examples? It’s tempting to make a transpiler
> plugin to see how it works in practice, but I’d like to see more examples
> first. Thanks
>
> On Sat, Apr 25, 2020 at 1:12 PM Jacob Bloom
> wrote:
>
>> Maybe it would be less footgunny to support autovivification in
Maybe it would be less footgunny to support autovivification in a more
class-based way, like Python does?
```javascript
class AutoVivArray extends Array {
[Symbol.getMissing](identifier) {
/* if we're here, identifier is not an ownProperty
* and is nowhere on the prototype chain */
> It seems to me like you are doing block logic without blocks, which I think
> increases the chances of bugs.
I agree. Without curly braces, it's not always clear when the parallel
code is guaranteed to have executed by. The first version of my
proposal did something similar:
```javascript
>>This [current] structure is also just fundamentally different from working
>>serially in async/await and it forces you to reason about the problem in a
>>specific way. This doesn't appear to be a conscious decision to force good
>>code practices
>
>Actually I'd argue that it is. Doing stuff
uelbarzi wrote:
>>
>> AFAIK `await` can only accept an `expression` as a `Promise`, not other
>> thing:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await
>>
>> On Thu, Nov 21, 2019 at 10:46 AM Jacob Bloom
>> wrote:
>>>
which is what the proposed syntax
is trying to avoid.
On Thu, Nov 21, 2019 at 2:41 AM Jacob Bloom wrote:
>
> >Just FYI, I previously suggested a couple things substantially more
> >flexible than this
>
> Ah, thank you for bringing those proposals to my attention. I looked
> thr
https://github.com/isiahmeadows/proposal-generator-fork
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom wrote:
> >
> > ...strike that, I misread the "but that still waits for the async
> &
ially like this:
```javascript
const x = doSomethingAsync();
const y = doSomethingElseAsync();
await x, await y;
// all promises are resolved by now, but
// still need to use await to unbox the values
someFunction(await x, await y);
```
On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom wrote:
>
> &g
>Maybe if you drop the "await" in your example:
>
>```javascript
>await.all {
>const x = doSomethingAsync();
>//x is just the promise here
>}
>```
>
>...but that still waits for the async functions to complete, I think it would
>cause fewer bugs and would seem to still satisfy the
out `await.race`, `await.allSettled`,
>> `await.any`?
>>
>> On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom wrote:
>>>
>>> To simplify the problem of working with promises in parallel, I
>>> propose this new syntax:
>>>
>>> ```javascrip
errors. I'd have to think more about its
use cases but it could be implemented the same way.
On Tue, Nov 19, 2019 at 9:20 PM Jordan Harband wrote:
>
> If we have `await.all`, what about `await.race`, `await.allSettled`,
> `await.any`?
>
> On Tue, Nov 19, 2019 at 7:45 PM Jac
To simplify the problem of working with promises in parallel, I
propose this new syntax:
```javascript
async function initialize() {
let foo, bar, baz;
await.all {
foo = (await request('foo.json')).data;
bar = (await request('bar.json')).data;
baz = (await
What about special handling for Maps? Maybe something like
```
const requests = new Map();
requests.set('reqA', fetch('...'));
requests.set('reqB', fetch('...'));
const responses = await Promise.all(requests);
console.log(
responses.get('reqA'),
responses.get('reqB'),
);
```
...which would
> And things such as E4X already exist.
Building on that, JSX is just a code transformation that can be used
without React. You can swap React out for another compatible library
with a pragma:
https://babeljs.io/docs/en/next/babel-plugin-transform-react-jsx#pragma
-- JSX + a React-like library
20 matches
Mail list logo
