This plugin simplifies field names in the PostGraphile schema; e.g.
allUsers
becomes simply users
, User.postsByAuthorId
becomes simply
User.posts
, and Post.userByAuthorId
becomes simply Post.author
.
Adding this plugin to your schema is almost certainly a breaking change, so do it before you ship anything! This is the primary reason this isn't enabled by default in PostGraphile.
This plugin is recommended for all PostGraphile users.
This plugin is implemented as a single JS file that does not need to be compiled at all - you can simply copy it into your project and customise it as you see fit.
Alternatively, you can write your own inflection plugin.
Given these tables:
create table companies (
id serial primary key,
name text not null
);
create table beverages (
id serial primary key,
company_id int not null references companies,
distributor_id int references companies,
name text not null
);
Query.allCompanies
👉Query.companies
(disable viapgSimplifyAllRows = false
)Query.allBeverages
👉Query.beverages
Beverage.companyByCompanyId
👉Beverage.company
Beverage.companyByDistributorId
👉Beverage.distributor
Company.beveragesByCompanyId
👉Company.beverages
(because thecompany_id
column follows the[table_name]_id
naming convention)- All update mutations now accept
patch
instead ofcompanyPatch
/beveragePatch
(disable viapgSimplifyPatch = false
) - If you are using
pgSimpleCollections = "only"
then you can setpgOmitListSuffix = true
to omit theList
suffix - Fields where the singular and plural are the same and a distinct plural is required are force-pluralised ("fishes") to avoid conflicts (e.g.
singularize("fish") === pluralize("fish")
).
Note: Company.beveragesByDistributorId
will remain, because distributor_id
does not follow the [table_name]_id
naming convention, but you could rename this yourself with a smart comment:
comment on constraint "beverages_distributor_id_fkey" on "beverages" is
E'@foreignFieldName distributedBeverages';
or with a custom inflector:
module.exports = makeAddInflectorsPlugin(
{
getOppositeBaseName(baseName) {
return (
{
// These are the default opposites
parent: "child",
child: "parent",
author: "authored",
editor: "edited",
reviewer: "reviewed",
// 👇 Add/customise this line:
distributor: "distributed",
}[baseName] || null
);
},
},
true
);
yarn add @graphile-contrib/pg-simplify-inflector
or
npm install --save @graphile-contrib/pg-simplify-inflector
CLI:
postgraphile --append-plugins @graphile-contrib/pg-simplify-inflector
Library:
const PgSimplifyInflectorPlugin = require("@graphile-contrib/pg-simplify-inflector");
// ...
app.use(
postgraphile(process.env.AUTH_DATABASE_URL, "app_public", {
appendPlugins: [PgSimplifyInflectorPlugin],
// Optional customisation
graphileBuildOptions: {
/*
* Uncomment if you are using `simpleCollections: 'only'` and you never
* want relay connections
*/
//pgOmitListSuffix: true,
/*
* Uncomment if you want 'userPatch' instead of 'patch' in update
* mutations.
*/
//pgSimplifyPatch: false,
/*
* Uncomment if you want 'allUsers' instead of 'users' at root level.
*/
//pgSimplifyAllRows: false,
},
// ... other settings ...
})
);
By naming your foreign key along the lines of author_id
or author_fk
, e.g.:
CREATE TABLE posts (
id serial primary key,
author_id int not null references users,
...
);
We can automatically extract the field prefix: author
and call the relation
author
rather than the default: user
. This allows for a post to have an
author
, editor
, reviewer
, etc. all which point to users
.
The reverse, however, is not so easy. On the User type, we can't call the
reverse of all these different relations posts
. The default inflector
refers to these as postsByAuthorId
, postsByEditorId
, etc. However we'd
rather use shorter names, so we introduce a new inflector:
getOppositeBaseName
. This inflector is passed a baseName (the part without
the _id
/_fk
suffix, e.g. author
, editor
, reviewer
above) and should
return the opposite of that base name which will be prepended to the target
type to produce, e.g. authoredPosts
, editedPosts
, reviewedPosts
.
Failing this, we just fall back to the default inflector; it will be up to
you to add smart comments or a custom inflector to override these.
In most cases, the conflict errors will guide you on how to fix these issues using smart comments.