Closed Zverik closed 2 years ago
Hey! I've had a go at this. Code is a bit of a mess at the moment so I haven't opened a PR yet.
Any suggestions for the UI? I'm not sure about also rendering geometry changes -- it would be quite complex and I think it would need a network request for each version.
Hey, this looks really nice and clean! It misses changeset comments, which I think are important. Other than that, it fits the editor, since it doesn't need geometry.
For rendering geometry, you would need to bulk request node history of every children node for all versions (and you receive their ids with a single query to /history
). It shouldn't be too many though. And that's for ways: for nodes you get all the history you need with the single request.
I'd incorporate geometry cards here in collapsed rows, and only for the first version and for these that have the geometry changed. But again, that's not mandatory: people usually refer to the history for tag changes.
Thanks for the feedback! I'll get the code polished up and open a PR.
I'll leave geometry diffs out for now, I agree just showing tag changes suits the editor well enough. The "No tag changes" message should make it clear that geometry changes aren't shown. Rendering the diff on a map probably will be quite involved too.
Showing the changeset comments should just involve one request to the changesets
endpoint. It says that it is limited to 100 id
s so it is okay for 99% of elements, and it can be chunked if required. Most of the work will probably be creating some test element with 101 versions on the dev API :)
I think you can cap the number of versions at ~30 :)
See #263 for discussion and prior work.