humanmade / repress Goto Github PK

Right now, data is pulled out of the store in the order the store contains it. This leads to the sorting not matching the archive.

isPostLoading uses loadingSingle, but the name of the key is actually loadingPost.

Currently, fetchOptions is merged with options directly, however this means you can't set common headers without them being overridden. We should deeply-merge these options, as well as any other properties used in Repress that need to be deeply merged.

withArchive is great. We should have a HOC for single posts too.

withArchive and withSingle should allow setting custom options like withRef

I find myself having to repeat the dynamic-archive style for things like pages all the time. We should build this in.

The above code can result in a posts arrays containing elements with index value of -1 if the post.id is not found. I think the if statement should probably be:

if ( position === -1 ) {
  return null;
}

This is a tracking issue for some design changes to Repress.

As we've worked with Repress more, some of the initial design decisions have turned out to be suboptimal. I'll attempt to summarise these below.

Too Post-Specific

Repress can deal with any standard REST API data that follows the pattern of /nouns?{query}, /nouns/{id}, and where the object looks like { "id": <int> }. However, the terminology throughout Repress refers to posts all the time, which makes things very weird when you have a list of e.g. categories.

#2 suggested changing this to a more generic items for withArchive. We need to change a fair few other bits too:

• In withSingle, rename the following props:
  • postId -> itemId
  • post -> item
• In withArchive, rename the following props:
  • posts -> items
• In handler, rename the following methods:
  • isPostLoading -> isItemLoading
  • isPostSaving -> isItemSaving
  • isPostCreating -> isItemCreating
  • isPostDeleting -> isItemDeleting
  • Consider renaming fetchSingle and friends to fetchItem
• In the state, rename the following keys:
  • loadingPost -> loadingItem
  • posts -> items

Too Repetitive

getSubstate is currently a function passed into methods as an argument. While this allows you to reuse the handler for multiple bits of state, the actions are already tied to the state location, so it turns out to be useless.

To reduce the amount you need to repeat yourself, we should move this to the handler instead: #1

Would it be possible to bump the redux dep to the latest version to avoid npm conflicts?

Rather than passing getSubstate into each helper method, should it instead be registered in the constructor? This would simplify it, but also removes some of the separation. Is that a good thing?

Hey,
I've just started to use repress to get the posts from our website and display them with react.
My problem is that I followed the tutorial 1:1 and still all posts and archives return undefined in the Component withSingle() and withArchive().
Although the store contains the post / archive with correct ID.

Completely stuck here and wondering if I made a typo or there's a small problem in the tutorial.

// Post.tsx
import {withSingle} from '@humanmade/repress';
import * as React from 'react';
import {posts} from "../types";

const Post = (props) => <article>
    <h3>{props.post.title}</h3>
</article>;

export default withSingle(
    posts,
    state => state.posts,

    props => props.id
)(Post);

// types.tsx
import {handler} from '@humanmade/repress';
import {config} from './config';

export const posts = new handler({
    type: 'posts',
    url: config.api.url + 'wp-json/wp/v2/posts'
});

posts.registerArchive( 'home', {} );
posts.registerArchive( 'stickied', { sticky: '1' } );

Returns TypeError: props.post is undefined.

Thanks for your help in advance!

Right now, we have hasMore/loadingMore/onLoadMore(). This allows implementing a "more posts" feature, however, there's no way to implement manual pagination.

In some cases, you may be able to short-circuit archive requests locally if you know how to match items on the client side.

For example, say you have a handler for posts, and you have dynamic archives using the slug:

props => {
    const query = {
    	slug: props.slug,
    };
    posts.registerArchive( `slug/${ props.slug }`, query );
    return `slug/${ props.slug }`;
}

As a developer, you know that WordPress de-duplicates slugs, so you can generate an authoritative search and skip the backend request if you happen to already have the post loaded in (from another archive/single request, e.g.).

It'd be good to have the ability to write a local matcher, which would still fall back to the backend. This local matcher would be treated as authoritative by Repress, so it should only be used when you know for certain that you're going to match.

Something like this:

    posts.registerArchive( `slug/${ props.slug }`, query, {
        localMatcher: posts => posts.filter( post => post.slug === props.slug,
    } );

(Naming tbd)

When a withArchive-wrapped component receives new props that necessitate a change to the archive ID, such as a change in route, how do you handle fetching the new post(s) if needed? It seems like the HOC's props.onLoad function might be using a resolvedId argument evaluated when the component initializes, so not sure how to get the new ID to handler.fetchArchive when the component is updating.

If you try to load in multiple items at the same time, you'll run into race conditions as isLoading will return false. We should instead store loading state as an array (or object), and check existence in the array instead.

We document the process of using archives, but not single items. May also want #4 first.

posts makes no sense as a key for non-post items like comments or users.

When connecting multiple components, avoid dispatching repeated requests. Instead, we should keep track of the current requests, and return the existing promise.

There's a typo in the lifecycle hooks for withSingle. They're checking _data.posts but should be checking _data.post. 🤦‍♂️