elf: [requests-status] initial status should not be pending

Which @ngneat/elf-* package(s) are relevant/releated to the feature request?

requests-status

Description

Currently, the library assumes that if there is a potential for requesting data, data will be requested right away. Thus, the initial status is set to pending. This assumption may not be correct. There could be a UX use-case where the requests for data would need to be initiated by the user action. The requirement could be that before the data was requested, a custom UI, that is different from the UI during the pending state, would be rendered. In order to enable this use-case, there should be a different state introduced for when the data was not yet requested.

Proposed solution

The StatusState should include one more state: NotAskedState:

export interface NotAskedState {
  value: 'notAsked';
}

The initial value should be set to the notAsked

Alternatives considered

I was considering to propose even a bigger change based on the RemoteData approach described in this article. This would enable frameworks to come up with another level of abstraction for components rendering the remote data. Here’s an example of such abstraction: https://github.com/joanllenas/ngx-remotedata.

Although, after giving it another thought, the RemoteData data structure is a bit limiting. For example, what if you wanted to keep displaying data while new data is loading? It seems like this scenario would not be possible with RemoteData approach.

So lets keep things simple and just introduced the notAsked status.

Do you want to create a pull request?

Yes

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 51 (36 by maintainers)

Most upvoted comments

I’ve merged the refactoring:

The initial value is now idle
DataSource is now more powerful, you can checkout the docs.

NetanelBasal on Oct 24, 2021

https://github.com/ngneat/elf/commit/390a639cf2b6518ab46ea78ea434eb29e2a5fff0

NetanelBasal on Oct 25, 2021

did some reading on the Repository pattern. I see the issue with my approach. I’m on board with Netanel’s recent suggestion.

DmitryEfimenko on Oct 23, 2021

@DmitryEfimenko I guess this way you force whole repo to depend on a service instance whereas service is just a data provider that could take different shapes or even be excluded. I knew nothing about that kind of antipattern but actually created it during my own experiments and then discovered that it’s quite bad practice.

strigefleur on Oct 23, 2021

I’m thinking about something like this:

// users.respository.ts

export const usersDataSource = createRequestDataSource({
  store,
  data$: store.pipe(selectAll()),
  requestKey: 'users',
  dataKey: 'users'
});

usersDataSource.data$.subscribe(({ users, loading, error }) => { ... });

setUsers(users: User[]) {
  store.update(
    setEntities(users),
    usersDataSource.setSuccess(),
    usersDataSource.setCached()
  );
}

// users.service.ts
http.get().pipe(
  tap(setUsers(users)),
  usersRepo.usersDataSource.trackRequestStatus(),
  usersRepo.usersDataSource.skipWhileCached()
)

And one variation for collections:

export const userDataSource = createRequestCollectionDataSource({
  store,
  data$: (id) => store.pipe(selectEntity(id)),
  dataKey: 'user'
});

usersDataSource.data$(id).subscribe(({ user, loading, error }) => { ... });

// users.service.ts
http.get(id).pipe(
  tap(addUser(user)),
  usersRepo.usersDataSource.trackRequestStatus(user.id),
  usersRepo.usersDataSource.skipWhileCached(user.id)
)

NetanelBasal on Oct 23, 2021

The initial value of requestsStatus is an empty object. When you update the state, it updates this object as follows:

{
  todos: {
    value: 'success'
  },
  todo: {
    value: 'pending'
  }
}

resetRequestsStatus means to set it back to an empty object:

{ }

When a key doesn’t exist here it will return the default value which currently is pending and now we’ll change it to idle.

NetanelBasal on Oct 21, 2021

@NetanelBasal

Lets imagine I have a button to disable while the request is loading: setRequestState will work as soon as I press the button however the button is disabled beforehead since the selectIsRequestPending already returns true. Isn’t it somehow wrong?

Following the logic I’d have to set request status to idle somewhere in store init which also feels a bit dirty. What would you do?

strigefleur on Oct 20, 2021

Sure, we can add it. However, I am not fond of this name. I prefer idle.

idle: The request hasn't started yet

NetanelBasal on Oct 6, 2021