| 01:30 | <jwalden> | huh |
| 01:31 | <jwalden> | never seen a "Translations (non-normative):" section at head of a spec before https://streams.spec.whatwg.org/ |
| 01:31 | <jwalden> | neat |
| 08:24 | <annevk> | JakeA: so in a way I see the appeal of using many objects, but on the other hand it's not really something we have precedence for |
| 08:24 | <annevk> | JakeA: is this how they do it in Node.js et al? |
| 08:24 | <annevk> | precedent* |
| 08:27 | <JakeA> | annevk: in node the conditions & handlers are JS, with maybe a function that returns a function. Eg decodeBody() would return a function that looks at the request and parses form data. Routers aside, React's props/state model has made plain objects pretty popular, and TypeScript makes them not-too-hard to create typings for. Not sure it's possible in WebIDL as it stands. |
| 08:29 | <JakeA> | annevk: I built https://github.com/jakearchibald/sw-routes/blob/master/README.md as an experiment a few months back. It's closer to how Express works |
| 08:30 | <annevk> | JakeA: what you sketched seems doable in IDL? |
| 08:32 | <annevk> | JakeA: library looks quite nice |
| 08:32 | <annevk> | JakeA: really wonder how builtin modules will shake things up going forward |
| 08:43 | annevk | notices Domenic made a similar comment some 10h ago |
| 08:45 | <JakeA> | annevk: I'll sketch something out. The thing I hit is: What do those functions return? If it's a special kind of object, why not have a constructor? If it's a plain object, why have the function? |
| 08:46 | <JakeA> | But I'll sketch an alternative and see how it goes |
| 08:49 | <annevk> | JakeA: I think it's important to realize that you need the functions for the polyfill, for something declarative you only need to pass instructions in some manner and ensure those instructions are not more powerful than the low-level API |
| 08:51 | <annevk> | Or alternatively, this would be a little higher-level still in that you need something that parses this and returns the necessary functions |
| 08:51 | <annevk> | s/parses/processes/ ... same same |
| 15:05 | <Domenic> | JakeA: FWIW I agree with the logic "What do those functions return? If it's a special kind of object, why not have a constructor? If it's a plain object, why have the function?" I just think the plain object route is worth exploring a bit more. |
| 15:47 | <JakeA> | Domenic: Yeah, thanks for prompting me to explore it more. I'm much happier with the plain object for the conditions. I'm not convinced about the sources, but it might not be a big deal if an enum can be used in the cases where options aren't needed |
| 15:48 | <Domenic> | Yeah I agree the sources are less obvious |
| 15:50 | <JakeA> | Domenic: How do you feel about the mix of enums and classes. Eg: `router.add(conditions, ['network', new RouterSourceCache('/offline.html')])`. The idea is you'd use `'network'` as a shorthand for `new RouterSourceNetwork()`, but if you needed to provide options, you'd need to use the constructor. |
| 15:51 | <Domenic> | I guess I still don't see why `new RouterSourceCache('/offline.html')` is better than `{ type: 'cache', url: '/offline.html' }` |
| 15:51 | <Domenic> | Assuming that the `RouterSourceCache` is just a dumb holder for precisely that `{ type, url }` data |
| 15:52 | <JakeA> | The problem is defining "url is a valid key of this object if the object also has key 'type' and its value is 'cache'" |
| 15:53 | <annevk> | JakeA: you could also put all the members in a dictionary and then throw for certain combinations |
| 15:54 | <Domenic> | Web IDL's constraints should not drive API design though. API design should drive us to expand Web IDL (if it happens more than once) or use prose (the first time) |
| 15:54 | <Domenic> | Yeah that's what MutationObservers do IIRC |
| 15:54 | <annevk> | uhuh |
| 15:55 | <JakeA> | Fair. I'm been thinking for a while that I should provide TypeScript definitions along with specs. This would be a case where I'd want to do that, as I'd like the TypeScript typings to be stricter than the WebIDL |
| 15:56 | <annevk> | The TypeScript community would probably like that |
| 15:58 | <JakeA> | annevk: Domenic: If I'm going down the all-object path, it really feels like we'd need a method to test if a condition/source is supported. Any objections? |
| 15:58 | <JakeA> | `router.supportsCondition('date', { to: Date.now() });` |
| 15:59 | <Domenic> | Seems reasonable I suppose; haven't thought too hard. |
| 15:59 | <annevk> | JakeA: the dictionary path you mean? I'd say only add it once you add something that needs it |
| 15:59 | <annevk> | JakeA: because for v1 presumably all UAs will implement the v1 version |
| 16:00 | <JakeA> | annevk: Fair enough. As long as we could add it later, else we kinda lock ourselves into the V1 set. |
| 16:01 | <annevk> | Hopefully we'll always be able to add stuff 😃 |
| 16:01 | <annevk> | And if we can't then I suppose it doesn't matter anyway |