Spruce up the README #25
Conversation
|
Just a heads up - this is fairly significant change, I'll take somewhat longer to get around and review it. |
|
The paragraphs are mostly the same, just refitted to match the usual 80-character width limit. And I moved the URLs out to make the plaintext nicer on the eyes. Otherwise yes, the Type Tables are totally new. |
| attribute can define the expected Javascript representation of the variant, or | ||
| if [serde-rs/serde#1183] gets resolved. | ||
|
|
||
| [safe integer]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isSafeInteger |
There was a problem hiding this comment.
Personally I prefer to keep links inline as it makes it easier to edit/remove them without looking for definitions somewhere else in the file.
There was a problem hiding this comment.
I always keep the links underneath the paragraph they belong to, meaning they're always in one place and thus easy to find, but if you prefer inlined I can revert.
There was a problem hiding this comment.
Yeah I rarely want links together with each other, but rather with their surrounding contexts, so I'd prefer to revert.
There was a problem hiding this comment.
I've inlined all the URLs except two; the ones that appear in the chart above. Otherwise the chart would get quite ugly.
|
|
||
| ### Deserialization | ||
|
|
||
| | Javascript Type | Rust Type | |
There was a problem hiding this comment.
I like the table idea overall. I wonder though, if we go there, perhaps it's better to merge both tables into one, with one column for "idiomatic type" (both used for serialization and supported for deserialization) and another column for "other supported sources" (extra types supported for deserialization only).
There was a problem hiding this comment.
Sure I'm in favour of that.
There was a problem hiding this comment.
Are you planning to come back to this?
There was a problem hiding this comment.
After looking at it again, fusing the charts might be harder than we initially thought. Each serialization direction has information unique to it, as well as caveats, so maybe it's clearer to keep them separate?
About this - the proposals definitely had lots of forks & renames since that was written. Now it's interface types that in theory should alleviate that cost, but I'd rather just remove that sentence altogether and not promise anything at this point :) |
|
I will return to this soon. |
RReverser
force-pushed
the
master
branch
2 times, most recently
from
6c2e781 to
1517453
Compare
|
I'm going to change the main text to what the official wasm-bindgen guide has now that serde-wasm-bindgen is the official approach, but want to keep the table and your credits, so I'll merge this PR first. Thanks for your work! |
|
Thanks! |
This PR makes the README a bit easier to read in plain text, and also replaces the large type conversion bullet-lists with charts. This makes it easier to tell what types map to what at a glance.
Note regarding some of the content in
Motivation: The WASManyrefproposal seems to have been merged: WebAssembly/reference-types#140 (comment). How does that affect this README (or project)?