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

An API to change firebase reference? #39

Open
Blakeinstein opened this issue Aug 4, 2021 · 5 comments
Open

An API to change firebase reference? #39

Blakeinstein opened this issue Aug 4, 2021 · 5 comments

Comments

@Blakeinstein
Copy link

I want to provide multi file support. Instantiating multiple monaco editors can affect performance. I think we can use monaco's ITextModel api, to be able to track multiple files.

@0xTheProDev
Copy link

@Blakeinstein Can you provide some code example to explain your use-case?

@Blakeinstein
Copy link
Author

I am planning to add collab on multiple file documents, that I plan to write to a file on a remote machine. Now Currently I get around this by,

  1. Instantiating a single monaco editor.
  2. Creating a firebase reference.
  3. Implement a file tree, and on item select, I dispose off any existing firepad instance, then create a new firepad instance with a child ref corresponding to that particular file.

This works overall, but I also need to list active users, and every file contains a separate user list. Which is useful to say which people are on the current file, but I then dont have a way to easily list all users.

I was interested in more of a native way of achieving this.

@0xTheProDev
Copy link

@Blakeinstein That's actually the right way to switch Firebase reference. We have some number of side effects associated with Firebase ref on creation of Firepad. These need to be handled well, and hence calling dispose() is crucial. One suggestion I can provide, is to have another layer of abstraction between Firepad and you app, with a map between Monaco Model URI and their Firepad reference. You can make this map into a probabilistic data structure (a LRU perhaps), and have good first connection with limited memory footprint.

@Blakeinstein
Copy link
Author

That sounds great and I have been doing just that. Thanks!

Was interested in a more native way of doing this. where i dont have to maintain multiple users list.

@0xTheProDev
Copy link

@Blakeinstein Let me think it through if we can expose some APIs with User presence data.

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

No branches or pull requests

2 participants