When minified with webpack I get lots of invalid XRef stream errors and no rendered PDF about react-pdf-js

[leebenson]

The issue is this this Uglify option.

Per uglify's docs:

pure_getters -- the default is false. If you pass true for this, UglifyJS will assume that object property access (e.g. foo.bar or foo["bar"]) doesn't have any side effects. Specify "strict" to treat foo.bar as side-effect-free only when foo is certain to not throw, i.e. not null or undefined.

That probably means that accessing some kind of property within the library has some kind of side-effect- mutating another variable, or doing something than 'purely' accessing a property.

I'll remove all Uglify compress options from the next version of ReactQL, because obviously we can't control how third-party packages work. The net result is that some packages will be slightly more inflated than others, but generally not more than a few %.

In the meantime, deleting that line from your ReactQL kit should solve it.

[leebenson]

@tsdexter - I've released the new version of ReactQL (and bumped the CLI) that removes the compress options. It seems to be working well with react-pdf-js now.

I also bumped to Webpack v3, which had the nice side effect of shaving a few kb off the final vendor size, so you might find that even without the compress options, it weighs in a little lighter 😄

[tsdexter]

Here is the component

import React from 'react';

// UI
import { Segment, Button } from 'semantic-ui-react'
import PDF from 'react-pdf-js';

class PDFViewer extends React.Component {
  constructor(props) {
    super(props);
    this.state = {}
    this.onDocumentComplete = this.onDocumentComplete.bind(this);
    this.onPageComplete = this.onPageComplete.bind(this);
    this.handlePrevious = this.handlePrevious.bind(this);
    this.handleNext = this.handleNext.bind(this);
  }

  onDocumentComplete(pages) {
    this.setState({ page: 1, pages });
  }

  onPageComplete(page) {
    this.setState({ page });
  }

  handlePrevious() {
    this.setState({ page: this.state.page - 1 });
  }

  handleNext() {
    this.setState({ page: this.state.page + 1 });
  }

  renderPagination(page, pages) {
    const previousButton = <Button disabled={page === 1} onClick={this.handlePrevious}>Previous Page</Button>
    const nextButton = <Button disabled={page === pages} onClick={this.handleNext}>Next Page</Button>
    return (
      <Button.Group attached='top'>
        {previousButton}
        <Button basic as={Label}>{`Page ${page} / ${pages}`}</Button>
        {nextButton}
      </Button.Group>
    );
  }

  render() {
    const {url} = this.props
    let pagination = null;
    if (this.state.pages) {
      pagination = this.renderPagination(this.state.page, this.state.pages);
    }
    return (
      <div>
        {pagination}
        <Segment attached textAlign="center">
          <PDF file={url} onDocumentComplete={this.onDocumentComplete} onPageComplete={this.onPageComplete} page={this.state.page} />
        </Segment>
      </div>
    )
  }
}

export default PDFViewer

[leebenson]

I'm not familiar with this library, so I can't give any more specifics without playing around with it first. But generally, there are two issues that can prevent the production build (or indeed, any server render) from working properly:

1. Client-only libs. If this is not intended to work on Node, then library instantiation should go inside a 'safe' function that only executes on the client - such as componentDidMount. You can use a Webpack import() promise or just a standard require() statement to pull the library in client-side.

2. File paths changing. Because a server is build in dist/server.js, if you're passing in a path name that's relative to your original source tree, that may break down when you're trying to re-use that same path from within the new server. I haven't tested this, but you'd probably need an absolute path to be sure.

It may not have anything to do with either of the above, but those are common situations that can throw up differences between the two environments.

I'll play around with this when I have a little more time and let you know what I find.

[tsdexter]

Thx @leebenson appreciate the insight. I'll try to get an example up with a barebones ReactQL that reproduces the issue. If you look at it before me, you can likely rule out #2 as I'm using hosted absolute GraphCool URLs for the PDFs

[tsdexter]

@leebenson Here is a reproducible example: https://github.com/tsdexter/reactql-pdf-js

It will load the latest PDF from graph.cool and/or you can upload a new one. It works as expected in development mode.

In production, on load and you can see it gets the file as it knows the page count, it just doesn't render the PDF page and clicking through the pages causes more errors for each time it tries to render.

[tsdexter]

thx @leebenson I'll test it out tonight and confirm/close the issue if working.

[mikecousins]

Nice work @leebenson.

[tsdexter]

@leebenson thx. removing the compress option worked - smart to remove it from the kit as I just also had the same issue with later.js