Comments (5)
I think this is where we can be much more opinionated than in the main library, by the way. We’ll almost certainly need to do some guessing anyways (the params we get have already had lists turned into appropriately|separated|strings
, for instance, which we should to turn back into arrays or sets), and the code should be seen as a starting point for the developer, so we can afford the risk of not always generating fully correct code, if the benefit is that the code is more useful most of the time.
Specifically, I think we should generate code along these lines:
const session = new Session( 'en.wikipedia.org', {
formatversion: 2,
// (suggestion) errorformat: 'plaintext',
}, {
userAgent: 'm3api-ApiSandbox-helper', // change this :)
warn: console.warn,
} );
const response = await session.request( {
action: 'query',
meta: 'siteinfo',
siprop: set( 'general', 'statistics' ),
} );
We can hard-code a set of params that “usually” go into the constructor as default params for all requests (formatversion, uselang, errorformat, errorlang, …), and also suggest some of them even when they’re not in the actual parameters (errorformat above; I’d probably do this for formatversion and errorformat). This also means that, if the user already has a session constructor call with similar default params, the session.request()
call we generate will be more useful to them, since we’re keeping those params out of that call.
Figuring out which params should be arrays or sets will be tricky. The paraminfo API can help us a bit here, by at least telling us which of the params are multi-valued at all, but distinguishing between sets (mergeable) and arrays (don’t merge) will still be tricky. Maybe we’ll just hard-code a list of params appropriate for one type, and default to the other type for everything else, though I’m not even sure what that would be. (Also, the hook handler has to be synchronous, and we don’t have access to the API sandbox code’s copy of the paraminfo, so we’ll probably just have to request it upfront at initialization time.)
If we have the paraminfo, we can also figure out which request should use { method: 'POST' }
as the request options. (But that also leads towards #6, which still needs to be done.)
from m3api.
Big thanks to @anomiex for anticipating the usefulness of making the request formats extensible and introducing this hook, by the way ❤️
from m3api.
(Also, the hook handler has to be synchronous, and we don’t have access to the API sandbox code’s copy of the paraminfo, so we’ll probably just have to request it upfront at initialization time.)
Hm, come to think of it… does it have to be synchronous? We have to add some item to the array synchronously, but I don’t think there’s anything stopping us from modifying that item later, asynchronously. The hook gets run as soon as the params have been validated, before the API request itself is even sent, but the user will only see the result once they manually select our custom output format. So we should produce some decent code synchronously, but I don’t think there’s anything stopping us from asynchronously improving it further.
from m3api.
Some work in progress at https://meta.wikimedia.org/wiki/User:Lucas_Werkmeister/m3api-ApiSandbox-helper.js.
Also, as a user script, this code (unlike the rest of the repository contents) has to be non-modern, and it’s surprisingly annoying :D (especially having to use var
instead of const
)
from m3api.
documented and announced, now needs to be added to the README :)
from m3api.
Related Issues (20)
- Decide whether internal changes count as breaking or not HOT 3
- Handle batchcomplete in continuation HOT 5
- Show warnings by default HOT 1
- Clarify “modern” requirements HOT 1
- Publish documentation HOT 4
- Check package-lock.json compatibility in CI
- Keep connections alive in axios backend HOT 1
- Link to other m3api packages in README HOT 3
- Declare `session.defaultParams` and `session.defaultOptions` stable HOT 5
- Reconcile `core.js` exports with `browser.js` and `node.js` exports HOT 1
- Run browser tests in browser HOT 3
- Make retry customizable HOT 7
- Drop Node 12 support HOT 2
- Support file parameters (upload) HOT 14
- Add separate repo with examples HOT 1
- Login failure does not result in exception being thrown HOT 3
- Support non-200 HTTP status codes HOT 1
- Handle API warnings HOT 4
- OAuth support HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from m3api.