WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 4 months ago

#42737 assigned feature request

Add method wp.api.getModelByType for retrieving api models

Reported by: mkaz Owned by: adamsilverstein
Milestone: 5.0 Priority: normal
Severity: normal Version: trunk
Component: REST API Keywords: needs-patch
Focuses: javascript Cc:

Description

For Gutenberg, it will be easier and less error prone to fetch the wp.api.model by retrieving by type instead of creating a route and searching for the model that matches that route.

An open detail to work out is if namespacing is needed, can objects have the same name in different API namespaces in the same instance of wp.api. A potential solution could be an optional second argument.

For example: getModelByType( type, versionString = 'wp/v2' )

Related to #41111

Original Slack Discussion at: https://wordpress.slack.com/archives/C5UNMSU4R/p1511878493000062

Attachments (1)

42737.patch (1.8 KB) - added by mkaz 4 months ago.

Download all attachments as: .zip

Change History (7)

This ticket was mentioned in Slack in #core-js by mkaz. View the logs.


7 months ago

#2 @adamsilverstein
7 months ago

  • Owner set to adamsilverstein
  • Status changed from new to assigned

#3 @mkaz
7 months ago

The reference implementation is available at PR #3683 on Gutenberg https://github.com/WordPress/gutenberg/pull/3683

#4 @adamsilverstein
4 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.0

#5 @mkaz
4 months ago

Patch attached.

The mapping associative arrays were created outside of the getModelByType and getCollectionByType functions so that they can be extended or overwritten if necessary.

@mkaz
4 months ago

#6 @mkaz
4 months ago

This is no longer needed to support Gutenberg, the calls were changed to no longer map into Backbone models but to go straight to the API for data.

Change made in https://github.com/WordPress/gutenberg/pull/5253

I still think this change is better way to map models instead of the routes which can lead to error, but probably doesn't make sense to include if there isn't going to be any code to use the new functions.

Note: See TracTickets for help on using tickets.