Persist on text editor's content via localStorage

[earth2marsh]

Persist on text editor's content via localStorage

[mohsen1]

For starters we can persist the data on localStorage

[GerardSoleCa]

Hello!

I'm working on this issue for personal enjoy and entertainment. By now I've achived to persist yaml to session but instead of using a unique key, I'm using the YAML title (info.title). By doing this it's possible to save multiple files to localstorage and then retrieve them.

Now I've this feature working but I need to fix two little issues:

• Default YAML loading duplicates the file
• Saving text on top, is stuck on working...

PS: I don't know if I should open a new issue, or only this one...
PS2: I'll push a sample on my gh-pages to test and then a PR to this repository :)

[GerardSoleCa]

Issues addressed. I'm maintaining the yaml key as the current opened api, but it is saved as yaml and info.title. So header text is working fine and duplicates are not a problem.

[GerardSoleCa]

PR is done, hope you like it! :)

[mohsen1]

I didn't have a chance to try your branch. What happens when I edit the title? Do you save a new YAML per key stoke?

[GerardSoleCa]

If title is edited it will be saved as a new YAML API Key. I reuse the SwaggerEditorCache keystore and then add the title as a key, so the localstorage will look like:

ngStorage-SwaggerEditorCache : {
    "intro": true,
    "progress": 1,
    "yaml": "....",
    "Uber API": "....",
    "My Custom API": "...."
}

Example:
If I'm editing My Custom API its YAML will be saved to yaml key (maintain compatibility with listeners and loaders) and to My Custom API key in order to store any changes done to that API.

The keys [intro, progress and yaml] are not shown in the modal.

Now I'm working with the possibility to clean non-desired APIs

[mohsen1]

Thank you for your work on this. We have a plan for having a backend for the editor so you save Swaggers in a database with versioning. We are interested in JSBin model where we use path params (UUID) for identifier and another path param for versioning. Doing too much in client side has less value since you can't share all of those saved YAMLs and also if in middle of editing title you might see another YAML magically appear because it matched the title.

[GerardSoleCa]

That's true, too much work on user's premises. I didn't know about JSBin, I'll stay tuned for incoming updates!
Are you thinking about how will you implement that backend? In example nodejs+mongo?

[mohsen1]

Yes, I'm actually designing the backend API for such system. It's going to be very similar to JSBin. The way it works is, for the first time you visit editor it renders / for you. Then when you make changes, we automatically push URL state to /:id/1 where id is unique for your Swagger description. Now, every time you make changes, we update the content of the Swagger description in the DB. If you click save button, we save current document as final for version 1 and push URL state to /:id/2.

There is a bit more complexity to it, when you share your URL with someone else, if they make changes, because they don't have the "ownership" cookie in their browser we save that Swagger description as a new entity and push URL state to /:new-id/1 so people can't mess with each other Swagger specs.

Here is the Swagger for API I explained above:

swagger: 2.0
info:
  version: "1.0.0"
  title: Bins
  description: An api for bins
paths:
  /:
    get:
      responses:
        200:
          description: Renders empty bin
    post:
      parameters:
        - name: body
          in: body
          schema:
            type: string
      responses:
        200:
          schema:
            $ref: Bin
          description: Makes a new bin

  /:id:
    get:
      responses:
        200: 
          description: Gets latest version of the bin with `id`
    post:
      parameters:
        - name: body
          in: body
          schema:
            type: string
      responses:
        200:
          schema:
            $ref: Bin
          description: Makes a new version of the bin
    delete:
      responses:
        400:
          description: Delete is not supported

  /:id/:version: 
    get:
      responses:
        200: 
          schema:
            $ref: Bin
          description: Gets a specific version of a bin
    delete:
      responses:
        400:
          description: Deletes is not supported



definitions:
  Bin:
    properties:
      uuid: 
        type: string
      versions:
        type: array
        items:
          $ref: Version

  Version:
    properties:
      bin_id:
        type: string
      version:
        type: integer
      created_at:
        type: Date
      body:
        type: string

FYI @earth2marsh
@fehguy How can I describe that "ownership cookie" with Swagger?

[GerardSoleCa]

Hi,

I like that backend schema/idea but what happens if I'm editing my API and then I loose my cookies, or just change between browser/computer. The ownership of that API will be still recoverable?

[mohsen1]

Yes, if you have the link to your Swagger, you can navigate to it and start editing. You will get a new id and your version number starts from 1 again.

In very long run we can have user login and save documents under your user account.

[GerardSoleCa]

Nice!
I'll stay tunned about future releases!,

Thanks!

[mohsen1]

Closing this since we discussed the plans and concerns already