React-pdf: Page wrapping

[miracle2k]

Do I understand correctly that react-pdf currently does not attempt to do any page wrapping, that is, if the content overflows a page, I have to catch that myself and move it to a second page, correct? Any plans regarding this?

[diegomura]

Not yet. It's simple if you think about just a text page. But when thinking on nested Text elements, this becomes more tricky. In these cases, the other elements on the page should also be rendered in the new page to respect the layout? These are the type of questions we didn't answer yet. In addition to that, doing this will break Yoga's layout, so that's another issue to tackle.
I'm sure we can define some prop to explicitly enable this in the future, but it's not in the scope for the moment

[SPAHI4]

I need to generate a pdf file with random text, that can be a huge size.
Is there any way to catch it and generate another page?

[diegomura]

@SPAHI4 not yet, sorry. As I said above, I'm not sure how the API will be for this, or how to implement it. Feel free to research/implement a proposal

[SPAHI4]

@diegomura sad 😞
the API can look like

<Page>
  <Page.Header>
    <Text>Document title<Text>
  </Page.Header>
  <Page.Content>
   ...
  </Page.Content>
  <Page.Footer>
    { (number, all) => <Text>page {number} of {all}</Text>
  </Page.Footer>
</Page>

upd. or it's better just
```

{ (number, all) => (
page {number} of {all}
)}

[VrajSolanki]

Since react-pdf is not able to auto wrap to next page the my basic question is how people use it. since you use react components that mostly grow based on data, eventually everybody ends up calculating the size and comparing it to the page height.
Or is it that people use to generate static data?? Please Suggest.

[diegomura]

Hi @VrajSolanki !
I know from people that are using it for generating non-static data documents.
Unfortunately for the moment that's the only way. This is a feature I would like to see in the library, but that I couldn't tackle yet. I _think_ I will have some time on the following weeks to keep working on the lib, but until then, there isn't another solution rather than that.
Thanks :)

[tpreusse]

An <AutoPage> component with an size information callback would be super cool:

<AutoPage size='A4' style={styles.page} onElementRender={(element, context) => {
  if (element.height > maxPageHeight) {
    // custom element split logic
    // with context helper to measure parts or all children already available measured out
    return [
      elementPart1,
      context.newPage(),
      elementPart2
    ]
  }
  if (context.y + element.height > maxPageHeight) {
    return [
      context.newPage(),
      element
    ]
  }
  return element
}}>
  {elements}
</AutoPage>

Could be combined with the header/footer component proposal from @SPAHI4

[diegomura]

Hi everyone!
Thanks for your amazing proposals!
I will grab many things from them I say what I think and how I would implement it to keep the discussion opened:

1. Do not infer anything about the content structure
Having things such as Page.Header or Page.Footer it's a good idea, but the downside that I see about it is that we are inferring too much about the document that the user wants to create. I know, the most common use case is having a _header_ and a _footer_, but we shouldn't be tight to that. What I propose here is using the very same primitives, but specify a special _prop_ for elements that must repeat throughout pages (ex. fixed):

<Document>
  <Page>
    <View fixed>
      My Header
    </View>
    <Text>
      Content
    </Text>
  </Page>
</Document>

This way, if the content exceeds the page area, a new page will be created to render the rest, and all the fixed elements will be rendered on it also.

2. Functions children
I think we should implement this in all elements.

<View>
    { data => <Text>{data}</Text> }
 </View>

data will have all types of data about the document. currentPage and totalPages of course, but also document size, metadata, and stuff like that

3. onElementRender
@tpreusse liked the idea. This would expose a very powerful (but also hard to implement) API to the user to have more control of _what_ gets rendered and _how_ gets rendere

Sorry about the long comment. Would like to hear your thoughts, but I like to where this is going 😄