Since somebody asked me already elsewhere about the expected precedence of the operator, this would be my answer:
```js const result = await dbQuery(data)<?.rows; ``` would be the equivalent of ```js let result = await dbQuery(data); if (result != null && result.rows != null) result = result.rows; ``` or to better answer about precedence: ```js const result = (await dbQuery(data))<?.rows; ``` I hope this adds some extra context to this proposal. On Fri, Sep 6, 2019 at 12:28 AM Andrea Giammarchi < [email protected]> wrote: > absolutely, I'm working with PostgreSQL these days and indeed for any > promise/awaited result this pattern looks like a win, and while it's > targeting a limitation of the chaining one, it can be used in various other > cases where knowing the initial result is more important than just falling > back to "_dunnoWhatHappenedThere_" > > On Fri, Sep 6, 2019 at 12:24 AM Michael Luder-Rosefield < > [email protected]> wrote: > >> Another pattern it could be useful in is with, say, nosql dbs where >> something might be an object or id reference: >> >> ``` >> const fooId = foo<?.id; >> ``` >> >> On Thu, 5 Sep 2019, 23:03 Andrea Giammarchi, <[email protected]> >> wrote: >> >>> Another use case that I believe will be common is the following one: >>> >>> ```js >>> // current state of the art >>> const result = dbQuery(data)?.rows ?? 'did it just failed or what?'; >>> >>> // VS the "mice operator" >>> const result = dbQuery(data)<?.rows; >>> >>> // if it was rows >>> if (Array.isArray(result)) >>> console.log(result); >>> else if (result instanceof Error) >>> console.error(result.message); >>> else >>> console.warn(`unexpected result: ${result}`); >>> ``` >>> >>> Ideally, the "mice" should grant chaining up to its latest presence, but >>> I wouldn't know right now how to reference to it ... >>> >>> ```js >>> // if no ?? is needed, this might work >>> const result = dbQuery(data)<?.rows?.data?.entry; >>> >>> // if ?? is needed, no idea how to back-reference the latest successfull >>> "mice" result >>> ``` >>> >>> >>> >>> >>> On Thu, Sep 5, 2019 at 11:44 PM Tab Atkins Jr. <[email protected]> >>> wrote: >>> >>>> On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi >>>> <[email protected]> wrote: >>>> > >>>> > This is basically a solution to a common problem we have these days, >>>> where modules published in the wild might have a `default` property, to >>>> support ESM logic, or not. >>>> > >>>> > ```js >>>> > // current optional chaining logic >>>> > const imported = exported?.default ?? exported; >>>> > >>>> > // my "mice operator" proposal >>>> > const imported = exported<?.default; >>>> > ``` >>>> > >>>> > Semantically speaking, not only `<?` actually looks like a mice, it >>>> also points at its previous value in case the chaining didn't work. >>>> > >>>> > Beside the basic example, the "mice operator" might save CPU cycles >>>> when it comes to involving more complex expressions, i.e. >>>> > >>>> > ```js >>>> > // current "solution" >>>> > const thing = require('thing')?.default ?? require('thing'); >>>> > >>>> > // mice operator >>>> > const thing = require('thing')<?.default; >>>> > ``` >>>> > >>>> > This is also easily tranpilable, so kinda a no-brainer for modern dev >>>> tools to bring in. >>>> > >>>> > TL;DR specially for cases where an accessed property should fallback >>>> to its source, this operator might save both typing and CPU time whenever >>>> it's needed. >>>> >>>> I find it a rather curious pattern, that I'd never seen before! Is it >>>> used in anything besides this ESM-compat thing you're talking about? >>>> >>>> (Saving CPU cycles is not a convincing argument; it's trivial to write >>>> such a line over two declarations and avoid any expensive >>>> recomputations.) >>>> >>>> ~TJ >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
