21gramconsulting / next-rest Goto Github PK

The lib is now full of temporary unknown and any hacks just to move faster. Gotta get rid of them before release.

Within 21Gram we only use "string" identifiers. Numbers are not ok internally as they open the doors for exploits such as intel guesswork (autoincrements). Instead, we always stick to GUID, UUID, etc. expressed as string ¯_(ツ)_/¯

If someone out there in the wilderness would like to have number support, just hit a thumbs up or smthn, we don't have issues with voluntarily shooting yourselves in the foot.

Reminder:

/**
 * @summary Represents the identifier of a REST resource.
 * @description
 * This weirdo type makes sure that the identifier of a
 * REST resource is a `string` but keeps the door open for
 * more strongly typed identifiers.
 * @example
 * The most basic "untyped" string example:
 * ```ts
 * // This is a valid identifier
 * const id: Identifier<string> = 'foo';
 * // This is not a valid identifier
 * const id: Identifier<string> = 42;
 * ```
 * @example
 * A more advanced, typed example:
 * ```ts
 * type ServiceID = 'auth' | 'paymentGateway' | 'cms' | 'crm';
 * // This is a valid identifier
 * const healthCheckId: Identifier<ServiceID> = 'auth';
 * // This is not a valid identifier
 * const healthCheckId: ServiceID = 'foo';
 * ```
 */
export type Identifier<T> = T extends string ? T : never;

The API should work with RecordShape types instead of explicit Codec types. This will allow for more liberal internal treatment of Query and Resource coding and keep the doors open for a smarter way of autoquerying that we have internally.

expand capabilities for head, patch, and others for nice to have UX and dev-x features.

reminder:

const httpMethods = ['GET', 'POST', 'PUT', 'DELETE'] as const;
export type HttpMethod = (typeof httpMethods)[number];

export const isHttpMethod = (method: string): method is HttpMethod =>
  httpMethods.includes(method as HttpMethod);

The library has hard-coded nextjs default which covers for most nextjs use cases, but could misbehave in environments with highly-customized NextJS configurations.

This issue can easily be covered, but won't spend an effort now.

IF YOU NEED THIS ENHANCEMENT please upvote, comment, hit an emoji, do anything so that we know.

Internally we have some useful things we could to the lib.

Reminder:

/**
 * @summary A type representing a query to a REST resource.
 * @description
 * For now this is just an empty object, but it will be
 * extended in the future.
 * Internally at 21Gram we have a lot of utility stuff hung
 * on this type, we just have to normalize & collect them.
 * @group Core API
 */
export type Query<_Resource> = {};

When you create an endpoint like [[...id]].api.ts, you might have in the id parameter an array of stuff. Which may also be legitimate, like:

/api/translation/123/en-US

Right now we shit on our neck.
Gotta fix this.

There are these great utilities:

isProcessing
isNoResult
isException
isResult

They could take more than one parameters :)

In which case if any one of them failes, it'd return false, and would only return true if all of them pass ¯_(ツ)_/¯

as the subject says

It's too fucking frequent that we do this:

const [mediaSet] = useMedia();
  const [media, setMedia] = useState<Array<MediaModel>>([]);
  useEffect(() => {
    if (!isResult(mediaSet)) return;
    setMedia(Array.from(mediaSet));
  }, [mediaSet]);

Using sets is a good pattern so far BUT it's inconvenient in most cases when you just directly hook the SWR live sets into your GUI.

It'd be nice to have another hook which would simply wrap the clientHook you'd use and play this given game ( ͡° ͜ʖ ͡°)

With SWR 2's mutate function there were insane inconsistencies if I understood things correctly.

Maybe with the new v3 it's worth revisiting.