HN user
just added an example implementation in the xlsx viewer for search, but the code is yours to modify and customize. react-xlsx should expose the necessary functions to implement a custom search (by workbook/sheet etc...)
added some basic filtering/sort/search support, lmk what you think!
Hey! Very valid feedback - working on improving the file system component and overall site performance today
Responded above but the components like the file viewers should not depend on next. Please lmk if it gets pulled when installing via CLI
Thank you! Working on optimizing
Someone requested web components earlier so let me know if you make that happen!
Heard the performance feedback will work on it today!
Hey! Those components are used for the demo site, and shouldn’t ship or get installed when you install the components in the registry.
None of the ones in the registry should have next as a dependency, please lmk if otherwise
TIL those are called Miller columns !
Valid feedback a few other comments have mentioned , I’m going to try improving the home page tomorrow
We use react-pdf for the viewer which I believe uses pdf JS under the hood
We aren’t not trying to reinvent that engine, rather just provide a building block for people to plug in their design system to its controls
if you mean our docx viewer/editor specifically its hard to say without manually testing the visual fidelity with Word on some complex docx files
you are welcome to try it with your own documents and see, but its just one example we wanted to show. for the blocks that use the react-docx library, you can always copy the code and use a different method to render the docx file/thumbnails
it should be much faster on the individual component's page
the root page is a bit slow with all the viewers, in practice you probably wont have that many in your app on one page
coming back to this now and added it in a few places
on the demos - everything below the fold is lazy loaded but i will see what we can do to improve the mobile perf
i felt like we couldn't build much on top of react-markdown, which i think is what most people are using
we built a library @extend-ai/react-xlsx on top of it that renders the parsed contents onto a canvas
testing was mostly manual with a test corpus we generated. its not perfect but its pretty close for most files we've seen
nice - did you write a custom parser for PDF/DOCX? we wrote one for XLSX after running into event loop issues with sheet JS
thanks! would love to get your feedback
i can't promise its visually 1:1 with Word/Excel but its pretty close on the corpus we tested with
we'll try to make it more clear on the landing/introduction page!
thats fair and definitely something we can try supporting in the future. we started with React because of how familiar models are with shadcn and tailwind
we hope this can be useful for people building in React though!
hm seems to look ok on mine - is this on the root page?
yes - the pdf/docx viewer use react-virtual to virtualize the pages
the zoom should work with the bounding box highlights, we're working on adding rotation support
Hi! I'm one of the engineers at Extend that worked on this - one of our other engineers created a Rust XLSX/XLS parser that we ported to WASM to our @extend-ai/react-xlsx package which handles the rendering/charts. It exposes some hooks so users can use their own components for the toolbar
ideally we want people to rate based on quality - but i imagine some of the results are biased rn based on loading time
Nice, we're on Pinecone so maybe we can use this in the future. Could you see any way of integrating this with a token manager like Nango so our end users could integrate their own accounts?
Will check this out - it seems like its doing two separate searches where you specify two separate top K values. Curious what the trade offs are between this approach and weighting sparse/dense vectors
Glad to hear that! Btw you should be able to configure the chunk size and overlap when you upload through the UI, or when using our /upload API (https://docs.baseplate.ai/api-reference/documents/upload-doc...).
Thanks for the feedback Sébastien! 1. Are you adding documents through the API with URLs? URL parsing is only supported through the UI right now, through the API it will just add that url as the metadata. 2. Will add md support soon! 3/4. We are working on ways to give more configuration to how the context is formatted like you mentioned, keep an eye out for updates! 5. The response from the completion API should return a "search_results" array which includes the chunks and other columns/metadata/images. If the array is empty there may be something wrong in the search config, happy to hop on a call some time or help in our Discord
Hope this helps!
Hey! Loving the experience so far - we started the project before pgvector was supported on Supabase, and we want to support hybrid search as well (don't think pgvector supports this?)