The problem here lies in the fact that Typescript is correct. At some point in your application, the state will be null.

Imagine what would occur if you attempted to access the state before the API call had completed. Typescript safeguards against this.

You'll need numerous checks for this scenario, but it presents an opportunity to incorporate loaders.

type BLOGPOST = {name: string};
type ADMIN_BLOGPOST_STATE = {
  blogPost: null | BLOGPOST
}
const state:ADMIN_BLOGPOST_STATE = {
  blogPost: null
}

// .. eventually, API calls will update state.blogPost with a valid value

if (state.blogPost === null) {
   return <Loader/>
} else {
   return <BlogPost id={state.blogPost.id} title={state.blogPost.title}/>
}

Based on your query, I assume you are not inclined towards this approach and instead prefer a centralized check for such situations.

I also presume that you are willing to take the risk of a component accessing the state prematurely while implementing a catch-all loader during API calls.

One method I've used to tackle this issue in the past is initializing the state with a null value but convincing Typescript it's valid.

Typescript Playground

type BLOGPOST = {name: string};
type ADMIN_BLOGPOST_STATE = {
  blogPost: BLOGPOST // <-- no need for null here
}
const state:ADMIN_BLOGPOST_STATE = {
  blogPost: null! // <-- non-null assertion
};

// at this point, you can attempt to access state.blogPost.name without TS errors

// .. API calls eventually set state.blogPost to a valid value

// no need to validate since we assume it's always valid
return <BlogPost id={state.blogPost.id} title={state.blogPost.title}/>

The benefit of this approach is consolidating your assertions at the beginning.

The drawback is needing to be extra cautious about how you interact with your state. It's up to you to handle it carefully.

Dealing with this issue can be quite frustrating. While my answer may not completely resolve your question as you would like, I will still provide it in the hopes that it may assist someone.

In my experience, I have encountered and managed this issue in two ways, one of which is dependent on the framework being used:

• To handle scenarios where a value is certain to be non-null or non-undefined, consider using a compile-time type assertion like the compile-time non-null assertion post-fix operator !. This avoids explicit casting and helps with concise code. For example, even if state.blogPost could be null at runtime, you can use:

  state.blogPost![name] = value
  state.blogPost!.property = value
  

  This asserts that the state.blogPost value is non-null during compilation. Remember, this operator is only for compile-time checking and will throw an error at runtime if the value is nullish. In some cases, optional chaining can also be beneficial.

• In certain React frameworks like Next.js (SSR + CSR), initial properties needed for rendering can be fetched asynchronously from an API. The page will wait until the Promise resolves with the props before completing its render. Check out Next.js' documentation on getInitialProps(context) for more information on this approach.

  This example focuses on Next.js, but the concept applies to ensuring that the blog post is fetched prior to rendering to avoid nullish values both at compile-time and runtime.

On a side note, when using square bracket notation like x[y], consider any security implications. Consult this GitHub article discussing potential security issues in specific situations: https://github.com/nodesecurity/eslint-plugin-security/blob/master/docs/the-dangers-of-square-bracket-notation.md

Instead of relying on null, consider creating a distinct type to depict the state where data is still pending from the backend/database, like so:

type UnfetchedBlogPost {
  status: "unfetched";
}

type FetchedBlogPost {
  status: "fetched";
  post: BLOG_POST;
}

type BlogPostStatus = UnfetchedBlogPost | FetchedBlogPost;

This approach allows you to clearly indicate the UI's state prior to the blog post being loaded, which could be handy for incorporating a loading spinner or similar indicator. While your reducers will still need to check if the blog post is loaded, you can easily handle the scenario where it's not:

UPDATE_CATEGORY(state, action:UPDATE_CATEGORY) {
  // assuming state.blogPostStatus is of type BlogPostStatus...
  if (state.blogPostStatus.status === "unfetched") {
    return state;
  }

  // The state now refers specifically to a LoadedBlogPost, enabling access to state.blogPostStatus.post
},

Additionally, when working with Redux, it's advisable for your reducers to be pure functions that generate a new state object instead of modifying the existing state directly. Refer to the documentation for more information.

Instead of selecting a single correct answer, I found value in all the assistance provided to help me understand this concept.

In my approach, I made sure to handle UI status using a boolean variable called loading. This meant that before any data was loaded, the user would only see a loading spinner on the interface.

• To streamline the process, I decided to eliminate the null value and introduced an empty valid value for the initial state of blogPost. This empty value did not contain any content but had all the necessary properties and fully adhered to the BLOGPOST type.

This led to a new type definition:

type ADMIN_BLOGPOST_STATE = {
  blogPost: BLOGPOST
}

By making these changes, I eliminated the need for type assertions in the reducer and enabled the creation of more advanced hooks for accessing the state without concerns about type inconsistencies.

export function useAdminBlogPostProperty<K extends keyof TYPES.BLOGPOST>(propName: K): TYPES.BLOGPOST[K] {
  return useSelector((state: ROOT_STATE) => state.ADMIN_BLOGPOST.blogPost[propName]);
}

In summary, the loading status effectively controls the asynchronous behavior, preventing users from updating data that hasn't loaded yet. Removing the initial null value from blogPost ensured that it will always be a valid BLOGPOST, providing stability when writing code in Typescript.

I've recently devised a fresh approach to tackle this particular issue:

Allow me to present my state shape:

type ADMIN_BLOGPOST_STATE = {
  blogPost: BLOGPOST
}

I intend to stick with this structure because I am confident that all components accessing blogPost and expecting BLOGPOST will only be rendered after blogPost has been populated.

In order to bypass the need for creating a placeholder state to fulfill the initial state requirement, I have implemented the following method:

initialNullState.ts

// THIS FUNCTION ALLOWS TO PASS NULL AND STILL OBEY
// THE STATE CONTRACT. BECAUSE WE KNOW FOR SURE THAT
// BECAUSE INITIAL STATE WILL NEVER BE ACCESSED

export const initialNullState = <T extends unknown>() : T => {
  return null as T;
};

This function utilizes null but performs a type assertion for the required type.

Therefore, during the initial state setup (within my createSlice call, since I utilize @reduxjs/toolkit), I proceed in the following manner:

const getInitialState = (): PAGES.ADMIN_BLOGPOST => ({
  status: { loading: true, error: null, notFound: false },
  blogPost: initialNullState(),
});

The invocation of initialNullState() yields null, however, it conforms to the shape of BLOGPOST, thereby preventing any complaints from Typescript.

Naturally, it is imperative to ensure that every instance invoking your state does so only after the page has fully loaded and a blogPost: BLOGPOST object is truly available.