Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support params in <Resource /> name #3020

Closed
kopax opened this issue Mar 18, 2019 · 7 comments
Closed

Support params in <Resource /> name #3020

kopax opened this issue Mar 18, 2019 · 7 comments

Comments

@kopax
Copy link
Contributor

kopax commented Mar 18, 2019

Supports of params in <Resource /> name

We keep struggling creating customized list views.

Because <List /> is tightly coupled with the URL, it makes it complicated to use it in customRoutes.

What we want is to fetch and display a list of records with the react-admin UI.

We have tried to use <Resource /> to create more than one list view (It seems from #2903 (comment) that people can build most of the UI with the current react-admin without hassle).

I want a way to pass filter to the list within any <Resource />, for instance:

export default function ProjectServiceNewslettersList(props) {
  return (
    <List
      {...props}
      filter={{ project_id: match.params.id }} // <~~~ This will come from the URL using withRouter
      sort={{ field: 'id', order: 'DESC' }}
      filters={<ProjectServiceNewslettersListFilter />}
    >
      <Datagrid striped hover>
        <TextField source="name" />
        <ShowButton size="sm" />
      </Datagrid>
    </List>
  );
}

Reproduction

I have declared the resource as follow:

  <Resource
    name="projects/:projectId/services/:serviceId/newsletters/groups"
    list={ProjectServiceNewslettersList}
  />

Result

Params are not replaced in CRUD requests.

{"timestamp":"2019-03-18 20:00:48","status":404,"error":"Not Found","message":"No message available","path":"/projects/:projectId/services/:serviceId/newsletters/groups"}

Expected

We expect to query the backend with the replaced params of the url we are on when querying the list.

I assert this is not currently possible because <Resource />.

This would have helped us to set filter on <List /> using params from the URL and create more than one list per entities.

Is there another strategy I have not thought of?

If not, could this be implemented?

@kopax kopax changed the title Support params in <Resource /> Support params in <Resource /> name Mar 18, 2019
@kopax
Copy link
Contributor Author

kopax commented Mar 18, 2019

It is possible to re-use <List /> for custom list view through customRoutes and <List />, using withRouter and the name of the already declared resource.

@kopax kopax closed this as completed Mar 18, 2019
@kopax
Copy link
Contributor Author

kopax commented Mar 18, 2019

In fact, I see myself recreating 4 Crud <Route /> for that, that involve WithPermission each time.

That would be nice if that could be a default feature. We'll look how this can be done.

@fzaninotto
Copy link
Member

I think you can achieve that by writing your own <Resource> component alternative. If that's the case, we won't modify the core react-admin as you explain (that would be a breaking change anyway).

@kopax
Copy link
Contributor Author

kopax commented Mar 19, 2019

Fair enough, I will post a solution if we solve this on our side. Thanks

@kopax kopax closed this as completed Mar 19, 2019
@lucastoledo-dev
Copy link

I'm sorry but for while, there is a workaround?

@kopax
Copy link
Contributor Author

kopax commented Apr 12, 2019

Hi @lukastoledo not yet, this feature is something we would help use save some extra lines.

Instead we are use customRoutes to do that, if you have an idea of implementation of <Resource /> that could solve that matter, I would be very interested.

@dalisalvador
Copy link

Any news regarding this?
I find it really odd that nobody desperately needs this feature...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants