What problems would this solve? =============================== An MDN compat table could be generated from multiple loads of resources. However, this will slow down both the API and MDN pages. Instead, KumaScript should be able to make a single request that returns all the data needed to generate the table. Who would use this? =================== KumaScript or other embedding scripts would use this endpoint when generating feature set tables. What would users see? ===================== Users would see an MDN page and compat table loading quickly What would users do? What would happen as a result? =================================================== Users would be impressed with the speed of MDN, and embed compatibility tables in their own blog posts. Is there anything else we should know? ====================================== Draft API docs at http://web-platform-compat.readthedocs.org/en/latest/draft/views.html#view-a-feature-set
Commits pushed to master at https://github.com/mozilla/web-platform-compat https://github.com/mozilla/web-platform-compat/commit/e482171003f725bbcba37df04088d16988056746 bug 1063154 - Add `make install_jslint` Install node and JS lint in the virtualenv https://github.com/mozilla/web-platform-compat/commit/170c046154e24e403d224a8d313e4213d9faf995 bug 1063154 - Update to latest drf-json-api Drop workarounds that are now in main repository https://github.com/mozilla/web-platform-compat/commit/54fac61c7d28d92d6b9852ea4d9d3c64971f2d6f bug 1063154 - Working dynamic view All the data needed to generate the MDN section for a Feature, which is the Feature plus: - Features that are descendants of the Feature - Browsers, Versions, Sections, Specifications, and Maturities for those Features - Names of tables (Desktop, Mobile) and the order of tabs in the table - What Supports are 'important', for browsers where the support changed between versions. 100% test coverage, but there is still work to do: - The list view is like other resource list views (first 10 feature views), and isn't useful or performant. - The representations are larger than they need to be, due to the inclusion of nested data (~450K for one sample). - Multiple database queries are needed to render with a warm cache https://github.com/mozilla/web-platform-compat/commit/e3b65fa9fc4df995b9562ec9ae8d03de83659a2a bug 1063154 - Use cache for view_features https://github.com/mozilla/web-platform-compat/commit/ec4078b82a276fe3f30f0080fcd02d2d9565cd4b bug 1063154 - Remove reverse relations Removed most reverse relations from view_features in the linked instances. These are not needed for displaying an MDN table, and can get quite large. For example, you don't need to know the IDs of all the versions or a browser, just the ones in the table, which are all included in the linked.versions section. https://github.com/mozilla/web-platform-compat/commit/e04782a266d2a8bc61f3c2aa275c2a0e1114ed73 bug 1063154 - Better list for view_features Display the link to the view_features detail, as well as the feature representation minus the linked relations. https://github.com/mozilla/web-platform-compat/commit/11b0f4968f8171dec4c84286929e2a221a0350e7 fix bug 1063154 - Paginate deep feature trees Large feature trees, such as the root feature node for CSS, can include hundreds to thousands of descendant features, as well as an explosion of related items. This change detects a large feature tree and paginates the view into 100-feature chunks. For the CSS tree, it requires over 15 seconds and 1082 SQL queries to generate the first page on my laptop, and 3.5 seconds and 2 queries from a warm cache. This also caches the descendant IDs of small feature trees, for a slight performance improvement in the more common case.