Cellpage generator

Get Involved Contributing
1

Often when I create (generate) a new Cell I also want a new Page to put that Cell in.
A while ago I added support to the Page generator to also take a parameter. rw g page Category {categoryId} will generate a page, and update the routes, so that you can go to /category/54 and 54 will automatically be passed as categoryId to your page. For me, this parameter is often just passed on to a Cell to fetch some data using apollo/gql

So, my question is, would a rw g cellpage Category generator be useful to anyone else but me?

It would:

  1. Generate a CategoryPage that takes categoryId as a parameter
  2. Add <Route path="/category/{categoryId:Int}" page={CategoryPage} name="category" /> to my routes
  3. Generate a CategoryCell, with a query that takes categoryId as a parameter
    export const QUERY = gql`
  query CategoryQuery($categoryId: Int!) {
    category(categoryId: $categoryId) {
      categoryId
    }
  }
`

export const Loading = () => <div>Loading...</div>

export const Empty = () => <div>Empty</div>

export const Failure = ({ error }) => <div>Error: {error.message}</div>

export const Success = ({ category }) => {
  return JSON.stringify(category)
}
  4. Add the cell to the page, passing the categoryId along all the way to the cell that is obviously rendered on the page
    import CategoryCell from 'src/components/CategoryCell'

const CategoryPage = ({ categoryId }) => {
  return (
    <CategoryCell categoryId={categoryId} />
  )
}

export default CategoryPage
  5. Add tests for all of the above

Anything else that it could/should do?
Is this something that you would use?

2

Interesting idea for sure @Tobbe. I think my immediate reaction is trying to intuit the amount this generator would be 1) saving time and 2) useful. The amount of code to tie together a Page and Cell is fairly minimal.

But, you raise a good point that a Cell is almost always going to need a Page, correct?

To help me understand what prompted you to consider this, could you tell me more about your personal experience and workflow? Specifically how this process has been happening for you in your project(s).

3
  1. Not a lot per invocation, but so far in my project(s) I would have reached for this generator pretty much every time where I have previously used the cell generator had it existed.
  2. To me it would have been useful, but I’m also curious to hear what others think. That’s why I posted this topic

Yes, exactly!

Most recently I wanted to fetch all of the products that belong to a specific category in my web shop. So I created a CategoryCell, and so I also needed a CategoryPage to display that cell on.
Previously it has been a ProductsCell and ProductsPage to display a (paginated) list of all products.

Yes, to the point where I’m constantly thinking “This is such repetitive work, why can’t the generators just do this for me as well?!”

1 Like
4

Something like this makes me think the default should be Page+Cell. :thinking:

Ok, super curious to hear what others think. Especially @rob

5

I’m working on the Tutorial II right now and I just generated a cell that doesn’t need a page! I definitely wouldn’t make it a default—cells are definitely a standalone “thing” that you should be able to generate on their own.

I’m not in love with a generator called cellpage…what about a --page option you can pass to the existing cell generator? We’re going to start having more of those soon, like --javascript, --typescript, flags for skipping tests or stories…

1 Like
6

--page would definitely work for me.

On a related note we also discussed (on Discord) maybe having a --withLayout LayoutName option for the Page generator to make it wrap the generated page in a (already existing) layout. And --withLoading LoadingComponent --withEmpty EmptyComponent options for the cell generator to use those components as defaults for the various states.

About the --javascript and --typescript flags. I know they’re useful right now when RW is a bit of a mixed bag when it comes to TS/JS. But later, when RW is 100% TS I’m thinking those should be flags to Create-Redwood-App, and then the generators should just use whatever the entire project is using. No? Or do you see a usecase for ever generating js cells/pages/layouts in a TS project?

7

Exactly - I could see a Cell used on a Footer Component w/in a Layout that pulls CMS-links to pages.

I like having the generators be more “atomic” – the do one thing and one thing well.

8 times out fo 10 I will refactor my Cell into multiple components anyway.

Even if it creates the import in the Page, I will have to move the cell component to where i want it in my page as well.

The one repetitive task that I would like to see in the Cell Template/Generator is plural vs singular:

WidgetCell vs WidgetsCell

  • Singular - stringify the gql result of the Widget
  • Plural - map the qql result on the Widgets as a ul and with an index and key on li with the stringified Widget

Or even, when making WidgetsCell do the map but also make a Widget componet that is rendered via the map.

I think having

  • custom templates
  • super generators (ie generator chaining)

could help here vs baking in much more logic and options into each template.

8

Yeah, this is the unix tool philosophy, but it also stipulates that you can chain the atomic things together, which we can’t do with the generators.

Just to be clear, this would only work with creating new pages. It would not try to add the cell to an existing page. At least that was my initial plan.

:100: would be awesome!

I see we both came to the same conclusion :slight_smile: