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

WIP: stub of Living Papers preview pane in TEE #44

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

geoffreylitt
Copy link
Collaborator

This is a tiny preliminary sketch of a Living Papers preview pane in TEE. You can edit a Markdown doc in the left pane and see the PDF from Living Papers update live in the right pane.

CleanShot 2024-04-21 at 17 36 04@2x

All the actual work here is happening in the automerge-based LP compile process that @joshuahhh created. The goal of this PR is as an initial exploration to 1) start thinking about how a deeper integration into TEE might be shaped, in terms of UX and software composition, and 2) serve as a testbed for ongoing work to support this use case better, e.g. supporting asset import.

how to run this in local dev

other repos worth being aware of:

design issues

  • this prototype adds a new datatype and editor component specific to LP. the editor component delegates the source editing to TEE, and handles the build + preview pane. are there more general / compositional approaches to creating this kind of experience? (eg: could it be expressed in a view composition tiling system without code)
  • data format: for ease of integration w/ current patchwork, it's most convenient to store everything in one doc. how do we handle the preview output data? (currently i'm persisting it but probably we should just treat it as ephemeral in-memory state?)

todos

  • raw latex support, should have a similar structure to LP, just running a different command on the server
  • assets support
  • bring this to patchwork with versioning
  • export PDF / zip
  • think about how the server component would fit into our deployment setup? (maybe could model it as a daemon service that's watching docs on the sync server for requests? we could also handle LLM requests this way.)

Copy link

netlify bot commented Apr 21, 2024

Deploy Preview for tee-production ready!

Name Link
🔨 Latest commit 8e56a78
🔍 Latest deploy log https://app.netlify.com/sites/tee-production/deploys/66258a3cbb39a60008fe8037
😎 Deploy Preview https://deploy-preview-44--tee-production.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link

netlify bot commented Apr 21, 2024

Deploy Preview for tangerine-dolphin-eefe36 ready!

Name Link
🔨 Latest commit 8e56a78
🔍 Latest deploy log https://app.netlify.com/sites/tangerine-dolphin-eefe36/deploys/66258a3cda7d1b000879e12c
😎 Deploy Preview https://deploy-preview-44--tangerine-dolphin-eefe36.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@joshuahhh
Copy link
Contributor

Very cool.

I was intrigued as to why your PDFViewer was so much simpler than mine (at https://github.com/joshuahhh/lp-viewer/blob/main/src/BuildsViewer.tsx). Memory is hazy but I think the main difference is that my version keeps an old PDF visible while a new PDF loads invisibly, so changing the document doesn't produce flickering. Something to consider if you notice that as a problem.

// Assuming there's a function to fetch data from a URL
console.log(`Fetching data for docUrl: ${docUrl}`);

const buildResult = await fetch(`http://localhost:8088/build/${docUrl}`);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔

// "pdfjs-dist/build/pdf.worker.min.js",
// import.meta.url
// ).toString();
pdfjs.GlobalWorkerOptions.workerSrc = `//unpkg.com/pdfjs-dist@${pdfjs.version}/build/pdf.worker.min.js`;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clemens' universal-automerge-cache strategy could come in handy here.

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

Successfully merging this pull request may close these issues.

3 participants