Provide functionality to generate shareable links that include the encoded template data.

[sanketshevkar]

Feature Request 🛍️

• Serialize and encode template data into a URL-friendly format.
• Provide functionality to generate shareable links that include the encoded template data.
• Decode and load the template data from the URL when the playground is accessed via a shared link.

Use Case

Possible Solution

Context

Detailed Description

[sanketshevkar]

I found this. And looked around, looks like this is a standard approach. What is happening here?

• The state object is stringified as storing complex JSON nested objects in the URL can be challenging.
• The this string is compressed using some LZ compression library which is provides lose-less compression. Need to check: Is the final form binary?
• The compressed string is base64 encoded then appended to the URL.

Questions to be investigated here:

• Why base64 encoding is required. My assumption is that after compression we would get a binary form for the stringified state object which cannot be shared using query params as we would require a string, so we encode it.
• How much size increase does base64 encoding cause? Is it still smaller than the stringified object itself? Can wejust share around the stringified object or the compressed form of the object?
• Upper limit of the state object that can be added to the URL using this method?

cc: @Vinyl-Davyl @mttrbrts @dselman

[sanketshevkar]

If we are going to use query parameters for state sharing, does saving the data in local storage still makes sense? The state in local storage is usually mapped to the URL. If we are storing the state in the URL itself. Should we even worry about storing it locally? https://github.com/accordproject/template-playground/issues/47

[sanketshevkar]

@mttrbrts had started discussion around if we would like to support uploading template-archive templates to load that template in the playground. In my view it'll be good if we keep this out of the scope for milestone 2. If we have time after milestone 3. This is something we should be looking into.

But we should start the discussion here, as the solution we build in this milestone should be extensible when we decide to develop the feature to upload and download a template.

I was wondering if could add the compression and base-64 encoding logic to template-archive itself and use it in playground? Something like getHash.

• I'm not sure if it'll be a good idea to instantiate the template in browser memory, but we can keep these new methods static too.
• Are we fixed on the folder structure for a template-archive folder?

[mttrbrts]

This looks like a great place to start, @sanketshevkar

I'm interested to know how far this can take us. For example, what is the expected upper bound on the maximum size of the template that can be expressed in this format?

[Vinyl-Davyl]

Hey guys, having done some work and taking inspiration from TS playground on the use and Implementation with LZ-String. I believe our threshold is 2mb max size, which I think is okay for us.

Would share some more details soon.

[Vinyl-Davyl]

Hey Guys,

After exploring the TS playground and implementing similar functionality in our project using LZ-String, I wanted to share our approach and findings regarding the state sharing and template size considerations and from what I've been building:

Our Approach to State Sharing:

1. Stringifying and Compression: We stringify our state object due to the challenge of directly storing complex JSON nested objects in URLs.
2. Compression with LZ-String: We use LZ-String for lossless compression to minimize the size of the state data.
3. Base64 Encoding: Post compression, perharps we base64 encode the compressed string. This is necessary because the compressed data might contain binary data which cannot be directly shared in query parameters.

Size Considerations:

• Threshold: Our current threshold for URL-shared state is around 2MB. Larger files, such as 3.6MB, do not consistently work across all browsers, especially Chrome.

  • Clarifications can be made in these created project with different share size:

  • 2mb file to be tried in TS Playground and shared cross diff browsers(works across all browsers): large_text_file_2mb.txt

  • 3.64mb file to be tried in TS Playground and shared cross diff browsers: large_text_file_2mb_5mb.txt

  • 7.28mb file to be tried in TS Playground and shared cross diff browsers: large_text_file_5mb_10mb.txt

• Size Impact: Base64 encoding increases the size of the data compared to the raw compressed string but remains smaller than the stringified object itself.

Future Considerations:

• Local Storage vs URL: With state now mapped to the URL, we reconsidered there is no need for the local storage, URL sharing is required.
• Expiration time function for shared links: Unless there's a specific expiration mechanism implemented in our application or the platform where the URL is shared, the URLs generated from the lz-string compression typically do not expire on their own

Project Milestones:

• Template Size Handling: Successfully tested up to 2MB files, reflecting our project's needs and capabilities.
• Browser Compatibility: Identified challenges with larger files on Chrome but generally workable across different browsers based on our testing.

Based on these findings and implementation inspired by TS playground utilizing the compression library LZ-String, our approach supports efficient state sharing via URL while considering browser compatibility and file size constraints. This sets a strong foundation for future enhancements, such as template-archive integration and additional features post-Milestone 3.

Hence, Work has commenced on this.

Would love to discuss further and iterations on these insights to ensure our approach aligns with project goals and future scalability.

cc: @sanketshevkar @mttrbrts @dselman