{"id":2485,"date":"2024-06-04T08:40:52","date_gmt":"2024-06-04T14:40:52","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=2485"},"modified":"2024-06-04T08:40:53","modified_gmt":"2024-06-04T14:40:53","slug":"testing-types-in-typescript","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/testing-types-in-typescript\/","title":{"rendered":"Testing Types in TypeScript"},"content":{"rendered":"\n

Say that 10 times fast.<\/p>\n\n\n\n

As your TypeScript usage gets more advanced, it can be extremely helpful to have utilities around that test and verify your types. Like unit testing, but without needing to set up Jest, deal with mocking, etc. In this post, we’ll introduce this idea. Then we’ll dive deeply into one particular testing utility that’s surprisingly difficult to create: a type that checks whether two types are the same.<\/p>\n\n\n\n

This post will cover some advanced corners of TypeScript you’re unlikely to need for regular application code. If you’re not a huge fan of TS, please understand that you probably won’t need the things in this post for your everyday work, which is fine. But if you’re writing or maintaining TypeScript libraries, or even library-like code in your team’s app, the things we discuss here might come in handy.<\/p>\n\n\n\n

Type helpers<\/h2>\n\n\n\n

Consider this Expect<\/code> helper:<\/p>\n\n\n

type<\/span> Expect<T extends<\/span> true<\/span>> = T;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
This type demands you pass true<\/code> into it. This seems silly, but stay with me.<\/p>\n\n\n\n
Now imagine, for some reason, you have a helper for figuring out whether a type is some kind of array:<\/p>\n\n\n
type<\/span> IsArray<T> = T extends<\/span> Array<\/span><any<\/span>> ? true<\/span> : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
You’d like to verify that IsArray<\/code> works properly. You could type:<\/p>\n\n\n
type<\/span> X = IsArray<number<\/span>[]>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Then mouse over the X<\/code> and verify that it’s true, which it is. But we don’t settle for ad hoc testing like that with normal code, so why would we with our advanced types?<\/p>\n\n\n\n
Why don’t we write this instead:<\/p>\n\n\n
type<\/span> X = Expect<IsArray<number<\/span>[]>>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
If we had messed up our IsArray<\/code> type, the line above would error out, which we can see by passing the wrong thing into it:<\/p>\n\n\n
type<\/span> Y = Expect<IsArray<number<\/span>>>;\n\/\/ error: Type 'false' does not satisfy the constraint 'true'.<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Better yet, let’s create another helper:<\/p>\n\n\n
type<\/span> Not<T extends<\/span> false<\/span>> = true<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
and now we can actually test the negative of our IsArray helper<\/p>\n\n\n
type<\/span> Y = Expect<Not<IsArray<number<\/span>>>>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Except these fake type names like X and Y will get annoying very quickly, so let’s do this instead<\/p>\n\n\n
\/\/ ts-ignore just to ignore the unused warning - everything inside of Tests will still type check<\/span>\n\/\/ @ts-ignore<\/span>\ntype<\/span> Tests = [\n  Expect<IsArray<number<\/span>[]>>,\n  Expect<Not<IsArray<number<\/span>>>>\n];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
So far so good. We can put these tests for our types right in our application files if we want, or move them to a separate file; the types are all erased when we ship either way, so don’t worry about bundle size.<\/p>\n\n\n\n
Getting serious<\/h2>\n\n\n\n
Our IsArray<\/code> type was trivial, as were our tests. In real life, we’ll be writing types that do more interesting things, usually taking in one or more types, and creating something new. And to test those sorts of things, we’ll need to be able to verify that two types are identical.<\/p>\n\n\n\n
For example, say you want to write a type that takes in a generic, and if that generic is a function, returns the parameters of that function, else returns never. Pretend the Parameters<\/code> type is not built into TypeScript, and imagine you write this:<\/p>\n\n\n
type<\/span> ParametersOf<T> = T extends<\/span> (...args: infer U) => any<\/span> ? U : never;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Which we’d test like this:<\/p>\n\n\n
\/\/ ts-ignore just to ignore the unused warning - everything inside of Tests will still type check<\/span>\n\/\/ @ts-ignore<\/span>\ntype<\/span> Tests = [\n  Expect<TypesMatch<ParametersOf<(a<\/span>: string<\/span><\/span>) =><\/span> void<\/span>>, [string<\/span>]>>,\n  Expect<TypesMatch<ParametersOf<string<\/span>>, never>>\n];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Great. But how do you write TypesMatch<\/code>?<\/p>\n\n\n\n
That’s the subject of the entire rest of this post. Buckle up!<\/p>\n\n\n\n
Type Equality<\/h2>\n\n\n\n
Checking type equality is surprisingly hard in TypeScript, and the obvious solution will fail for baffling reasons unless you understand conditional types. Let’s tackle that before moving on.<\/p>\n\n\n\n
We’ll start with the most obvious, potential solution:<\/p>\n\n\n
type<\/span> TypesMatch<T, U> = T extends<\/span> U ? true<\/span> : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
You can think of T extends U<\/code> in the same way as with object-oriented inheritance: is T the same as, or a sub-type of U. And instead of (just) object-oriented hierarchies, remember that you can have literal types in TypeScript. type Foo = \"foo\"<\/code> is a perfectly valid type in TypeScript. It’s the type that represents all strings that match \"foo\"<\/code>. Similarly, type Foo = \"foo\" | \"bar\";<\/code> is the type representing all strings that match either \"foo\"<\/code>, or \"bar\"<\/code>. And literal types, and unions of literal types like that can both be thought of as sub-types of string, for these purposes.<\/p>\n\n\n\n
Another (more common way) to think about this is that T extends U<\/code> is true if T can be assigned to<\/em> U, which makes sense; if T is the same, or a sub-type of U, then a variable of type T can be assigned to<\/em> a variable of type U.<\/p>\n\n\n\n
The obvious test works:<\/p>\n\n\n
type<\/span> Tests = [Expect<TypesMatch<string<\/span>, string<\/span>>>];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
So far, so good. And:<\/p>\n\n\n
type<\/span> Tests = [Expect<Not<TypesMatch<string<\/span>, \"foo\"<\/span>>>>];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
This also works, since a variable of type string<\/code> cannot be assigned to a variable of type \"foo\"<\/code>.<\/p>\n\n\n
let<\/span> foo: \"foo\"<\/span> = \"foo\"<\/span>;\nlet<\/span> str: string<\/span> = \"blah blah blah\"<\/span>;\n\nfoo = str; \/\/ Error<\/span>\n\/\/ Type 'string' is not assignable to type '\"foo\"'.<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
But we hit problems with:<\/p>\n\n\n
type<\/span> Tests = [Expect<Not<TypesMatch<\"foo\"<\/span>, string<\/span>>>>];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
This fails. The string literal type \"foo\"<\/code> is assignable to variables of type string.<\/p>\n\n\n\n
Just test them both ways<\/h3>\n\n\n\n
I know what you’re thinking: just test it from both directions!<\/p>\n\n\n
type<\/span> TypesMatch<T, U> = T extends<\/span> U\n  ? U extends<\/span> T\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
This solves both of our problems from above. Now both of these tests pass.<\/p>\n\n\n
type<\/span> Tests = [\n  Expect<Not<TypesMatch<string<\/span>, \"foo\"<\/span>>>>,\n  Expect<Not<TypesMatch<\"foo\"<\/span>, string<\/span>>>>,\n];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Let’s try union types:<\/p>\n\n\n
type<\/span> Tests = [\n  Expect<TypesMatch<string<\/span> | number<\/span>, string<\/span> | number<\/span>>>,\n  Expect<Not<TypesMatch<string<\/span> | number<\/span>, string<\/span> | number<\/span> | boolean<\/span>>>>\n];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Both<\/strong> of these fail with:<\/p>\n\n\n\n
\n
Type ‘boolean’ does not satisfy the constraint ‘true’<\/p>\n<\/blockquote>\n\n\n\n
Identical union types fail to match as identical, and different union types fail to match as different. What in the world is happening.<\/p>\n\n\n\n
Conditional types over unions<\/h2>\n\n\n\n
So why did this not work with union types?<\/p>\n\n\n
type<\/span> TypesMatch<T, U> = T extends<\/span> U\n  ? U extends<\/span> T\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Let’s back up and try to simplify. Let’s imagine some simple (useless) types. Imagine a square and circle:<\/p>\n\n\n
type<\/span> Square = {\n  length: number<\/span>;\n};\ntype<\/span> Circle = {\n  radius: number<\/span>;\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Now imagine a type that takes a generic in, and returns a description. If we pass in a Square, it returns the string literal type \"4 Sides\"<\/code>. If we pass in a circle, it returns the string literal \"Round\"<\/code>. And if we pass in anything else, it returns the string literal type \"Dunno\"<\/code>. This is very silly but just go with it.<\/p>\n\n\n
type<\/span> Description<T> = T extends<\/span> Square\n  ? \"4 Sides\"<\/span>\n  : T extends<\/span> Circle\n  ? \"Round\"<\/span>\n  : \"Dunno\"<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Now imagine a function to use this type:<\/p>\n\n\n
function<\/span> getDescription<\/span><T<\/span>>(obj: T<\/span>): Description<\/span><T<\/span>> <\/span>{\n  return<\/span> null<\/span> as<\/span> any<\/span>;\n}\nconst<\/span> s: Square = { length: 1<\/span> };\nconst<\/span> c: Circle = { radius: 1<\/span> };\n\nconst<\/span> sDescription = getDescription(s);\nconst<\/span> cDescription = getDescription(c);<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
sDescription<\/code> is of type \"4 Sides\"<\/code> and cDescription<\/code> is of type \"Round\"<\/code>. Nothing surprising. Now let’s consider a union type.<\/p>\n\n\n
const<\/span> either: Circle | Square = {} as<\/span> any<\/span>;\nconst<\/span> eitherDescription = getDescription(either);<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
The type\u00a0Circle | Square<\/code>\u00a0does not extend\u00a0Square<\/code>\u00a0(a variable of type\u00a0Circle | Square<\/code>\u00a0cannot be assigned to a variable of type\u00a0Square<\/code>) nor does it extend Circle. So we might naively expect\u00a0eitherDescription<\/code>\u00a0to be\u00a0\"Dunno\"<\/code>. But intuitively this feels wrong.\u00a0either<\/code>\u00a0is a Circle or a Square, so the description should be either\u00a0\"4 Sides\"<\/code>\u00a0or\u00a0\"Round\"<\/code>.<\/p>\n\n\n\n
And that’s exactly what it is:<\/p>\n\n\n\n
\"Union<\/figure>\n\n\n\n
Distributing union types<\/h2>\n\n\n\n
When we have a generic type argument that’s also a type union, pushed across an extends<\/code> check in a conditional type, the union itself is split up with each member of the union substituted into that check. TypeScript then takes every result, and unions them together. That<\/em> union is the result of that extends<\/code> operation.<\/p>\n\n\n\n
Any never<\/code>‘s are removed, as are any duplicates.<\/p>\n\n\n\n
So for the above, we start with our type:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
We substitute the union type that we passed in for T<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Once our conditional type hits the extends keyword, if we passed in a union type, TypeScript will distribute over the union; it’ll run that ternary for each type in our union, and then union all of those results together. Square is first:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Square<\/code> extends Square<\/code> so \"4 Sides\"<\/code> is the result. Then repeat with Circle:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Circle<\/code> extends Circle<\/code> so \"Round\"<\/code> is the result of the second iteration. The two are union’d together, resulting in the \"4 Sides\" | \"Round\"<\/code> that we just saw.<\/p>\n\n\n\n
Playing on Hard Mode<\/h2>\n\n\n\n
Let’s take a fresh look at this:<\/p>\n\n\n
type<\/span> TypesMatch<T, U> = T extends<\/span> U\n  ? U extends<\/span> T\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Here’s what happens with:<\/p>\n\n\n
TypesMatch<string<\/span> | number<\/span>, string<\/span> | number<\/span>>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We start:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Then substitute string | number<\/code> in for T and U. Evaluation starts, and immediately gets to our first extends<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
T and U are both unions, but only the type before<\/em> the extends<\/code> is distributed. Let’s substitute string | number<\/code> for U:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Now we’re ready to process that first extends<\/code>. We’ll need to break up the T union, and run it for every type in that union. string<\/code> is first:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
string<\/code> does extends string | number<\/code> so we hit the true branch, and are immediately greeted by a second extends<\/code>.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Think of it like a nested loop. We’ll process this inner extends<\/code> in the same way. We’ll substitute each type in the U<\/code> union, starting with string<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
and of course string extends string<\/code> is true. Our first result is true<\/code>.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Now let’s continue processing our inner loop. U will next be number<\/code>. number extends string<\/code> is of course false, which is the second result of our type.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
So far we have true | false<\/code>. Now our outer loop continues. T<\/code> moves on to become the second member of its union, number<\/code>. number extends string | number<\/code> is true:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
so we again hit that first branch:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The inner loop starts all over again, with U<\/code> first becoming string<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
string<\/code> extends number is false, so our overall result is true | false | false<\/code>. U<\/code> then becomes number<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
which yields true<\/code>.<\/p>\n\n\n\n
The whole thing produced true | false | false | true<\/code>. TypeScript removes the duplicates, leaving us with true | false<\/code>.<\/p>\n\n\n\n
Do you know what a simpler name for the type true | false<\/code> is? It’s boolean<\/code>. This type produced boolean<\/code>, which is why we got the error:<\/p>\n\n\n\n
\n
Type ‘boolean’ does not satisfy the constraint ‘true’<\/p>\n<\/blockquote>\n\n\n\n
We were expecting a literal type of true<\/code> but got a union of true and false, which reduced to boolean.<\/p>\n\n\n\n
It’s the same idea with:<\/p>\n\n\n
type<\/span> Result = TypesMatch<string<\/span> | number<\/span>, string<\/span> | number<\/span> | boolean<\/span>>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We won’t go through all the permutations. Suffice it to say we’ll get some mix of true and false, which will reduce back to boolean<\/code> again.<\/p>\n\n\n\n
So how to fix it?<\/h2>\n\n\n\n
We need to stop the union types from distributing. The distributing happens only with a raw generic type in a conditional type expression. We can turn it off by turning that type into another type, with the same assignability rules. A tuple type does that perfectly:<\/p>\n\n\n
type<\/span> TypesMatch<T, U> = [T] extends<\/span> [U]\n  ? [U] extends<\/span> [T]\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Instead of asking if T extends U<\/code> I ask if [T] extends [U]<\/code>. [T]<\/code> is a tuple type with one member, T. Think of it with non-generic types. [string]<\/code> is essentially an array with a single element (and no more!) that’s a string.<\/p>\n\n\n\n
All our normal rules apply. [\"foo\"] extends [string]<\/code> is true, while [string] extends [\"foo\"]<\/code> is false. You can assign a tuple with a single \"foo\"<\/code> string literal to a tuple with a single string, for the same reason that you can assign a \"foo\"<\/code> string literal to a variable of type string<\/code>.<\/p>\n\n\n\n
One last fix<\/h2>\n\n\n\n
We’re pretty much done, don’t worry.<\/p>\n\n\n
type<\/span> TypesMatch<T, U> = [T] extends<\/span> [U]\n  ? [U] extends<\/span> [T]\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;\n\ntype<\/span> Tests = [\n  Expect<Not<TypesMatch<string<\/span>, \"foo\"<\/span>>>>,\n  Expect<TypesMatch<string<\/span> | number<\/span>, string<\/span> | number<\/span>>>,\n  Expect<Not<TypesMatch<string<\/span> | number<\/span>, string<\/span> | number<\/span> | object>>>\n];<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
This mostly works, but there’s one rub: optional properties. This test currently fails<\/p>\n\n\n
Expect<{ a: number<\/span> }, { a: number<\/span>; b?: string<\/span> }>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Unfortunately both of those types are assignable to each other, which makes sense. The b<\/code> in the second type is optional. { a: number; b?: string }<\/code> can in fact be assigned to a variable expecting { a: number }<\/code>, since the structure of { a: number }<\/code> is satisfied. TypeScript is happy to ignore the extra properties. We’re really close though. This only happens if either type has optional properties which are absent from the other type.<\/p>\n\n\n\n
This already fails:<\/p>\n\n\n
Expect<{ a: number<\/span>; b?: number<\/span> }, { a: number<\/span>; b?: string<\/span> }>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Those types are not at all compatible. So why don’t we just keep what we already have and verify that all of the property keys are the same. We’ll rename a smidge and wind up with this:<\/p>\n\n\n
type<\/span> ShapesMatch<T, U> = [T] extends<\/span> [U]\n  ? [U] extends<\/span> [T]\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;\n\ntype<\/span> TypesMatch<T, U> = ShapesMatch<T, U> extends<\/span> true<\/span>\n  ? ShapesMatch<keyof T, keyof U> extends<\/span> true<\/span>\n    ? true<\/span>\n    : false<\/span>\n  : false<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
What was TypesMatch<\/code> is now ShapesMatch<\/code> and our real TypesMatch<\/code> calls that, then calls it again on the types’ keys. Don’t be scared of keyof T<\/code> \u2014 that’s safe. This will work on primitive types, function types, etc. So long as the types are the same, the result will be the same. If the types are object types, they’ll match up those object properties.<\/p>\n\n\n\n
Wrapping up<\/h2>\n\n\n\n
Conditional types can be incredibly helpful when you’re building advanced types for testing or otherwise. But they also come with some behaviors that can be surprising to the uninitiated. Hopefully this post made some of that clearer.<\/a><\/p>\n\n\n\n
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
This post explores advanced TypeScript utilities for testing and verifying type correctness, akin to unit testing without extra setup.<\/p>\n","protected":false},"author":21,"featured_media":2511,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[184],"class_list":["post-2485","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-typescript"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/06\/pexels-photo-938165.jpeg?fit=1880%2C1191&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/2485","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=2485"}],"version-history":[{"count":12,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/2485\/revisions"}],"predecessor-version":[{"id":2549,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/2485\/revisions\/2549"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/2511"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=2485"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=2485"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=2485"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}