handsontable / spreadsheet-viewer

Spreadsheet Viewer is a developer-friendly JavaScript tool that lets your users preview Excel files without leaving your web app

Spreadsheet Viewer

Spreadsheet Viewer is a software component that lets your users preview Excel files without leaving your web app.

✨ Try the live demo

Documentation

• Installation
• API guides
  • API overview
  • Query String API
  • JavaScript API
  • Web Messaging API
• Advanced topics
  • Frame assets
  • Product architecture
  • Error codes
  • Security
  • Customization
• Features and known limitations
• Open-source licenses

Licenses

A 30-day trial license is available on our website to all developers, who would like to try out the full functionality of Spreadsheet Viewer before purchasing.

After the 30-day trial period, you will be asked to purchase the commercial license. Or, just contact us any time.

Get in touch

• Contact sales
• Get technical support

---

© 2021 Handsoncode

spreadsheet-viewer's Issues

CORS proxy

I discussed it with @krzysztofspilka yesterday that we should offer a free CORS proxy to help the developers get a quick start with Spreadsheet Viewer. The CORS proxy removes the need to set the headers in XLSX file server HTTP responses, at the cost of using a middleman (our service).

The easiest way for us to offer the CORS proxy is via CloudFlare.

Tasks include:

• design a CORS API in SV that works automatically (if the workbook origin is different than the frame assets origin), but still make it possible to disable or change the proxy
• explain the new API in the docs
• write CORS proxy TOS (see below)
• deploy the CORS proxy service

We need to write Terms of Service that includes:

• the service is provided free of charge for end-users of SV
• the service is optional and is not required for SV to function
• the service purpose is to make changes to HTTP responses that allow loading files without being blocked by browser's cross-origin security protection (CORS)
• the service works by adding Access-Control-Allow-Origin headers to the response
• the service is only intended to work with certain document types (spreadsheets) and might not work with other kinds of resources (only certain mime types are allowed)
• the service uses third party cloud infrastructure provider (Cloudflare) and is subject to their TOS
• the service might add other headers and process the files in additional ways, including reading of the files and processing them for stats purposes
• we reserve the right to make API changes that will break compatibility with older versions of SV, or to disable the service with prior notice
• the service might reject the request if the target server takes too long to respond or if the response size is too large
• we reserve the right to limit the request rate (number of allowed requests in a time period)
• the service makes requests for third party servers on behalf of the user. We shall not take responsibility for unauthorized access to resources located at third-party servers nor for the amount of traffic generated by user requests and the consequences of it (hosting cost, DDOS attacks)

Maybe we could take a look at DNS, CDN, SSH tunnel services TOS for inspiration what else to include.

It is hard to debug situations when HTTP server removes svId

I tried hosting SV on a CDN like unpkg.com. In theory, such a CDN is capable of serving HTML files.

In practice, it turns out that a request to sv/index.html?svId=abc is treated with a 302 redirection that removes the query string parameter. The user is redirected to sv/index.html, which results in presenting the DeveloperWelcomeScreen instead of the expected XLSX file preview.

We should add more information both in the client library and in the SV frame to help identify the problem. I've spent an hour investigating it, thinking that this is some cross-origin issue.

Publish on NPM

We are going to make it easier to install SV in customers projects. As a part of that, the whole package will be published and distributed via NPM.

Client library does not work with CDNs that have strict requirements for the query string

I tried using the client library with frame assets hosted with CDNs skypack.dev and unpkg.com and they both have the same problem: Providing a custom query string (?svId=...) by client library results in an error or a 302 redirection.

The solution to this appears to be to use the hash (#) part of the URL instead of the search (?) part.

For that reason, I suggest that the URL parameters could be given either in the ?... part (ending at the URL end or the # character) or in the #... part.

Then we could rename the "Query String API" to "URL API". We could do it at once with https://github.com/handsontable/spreadsheet-viewer-dev/issues/942

Rename "Web Messaging API" to "Messaging API"

The name "Web Messaging API" is not intuitive. There is no such thing in the Web standards. There used to be a document "HTML5 Web Messaging", but actually it defines two methods of communication "Cross-document messaging" (used here) and "Broadcast messaging".

For short, we should call it "Messaging API"

Small DeveloperWelcomeScreen adjustments

Title change

The issue with titles applies to the general template that we see when a workbook is not loaded.
The name should be changed from 'Handsontable Spreadsheet Viewer' to ' Spreadsheet Viewer'.

Font-color

Issus related to font-color relates to the light mode of the themeStylesheet option.
As we can see below the light mode should load a darker font to the DeveloperWelcomeScreen message.

Tested on Chrome 87, Windows 10

Use a less popular port number 8080 in our developer samples

Use a less popular port number 8080 in our developer samples, because that people might have existing dev servers, service workers, etc running at that port. It is confusing that that happens.

hyperlink cell

it would be nice hyperlink text work