codelytv / p2p-editor Goto Github PK
View Code? Open in Web Editor NEWOnline code editor based on P2P and JavaScript. Demo:
Home Page: http://p2p-editor.codely.tv
License: MIT License
Online code editor based on P2P and JavaScript. Demo:
Home Page: http://p2p-editor.codely.tv
License: MIT License
Take advantage of WebRTC to build a communication audio channel between peers.
P2P Editor crashes while loading its home with querystrings in the URL.
We have a restriction because we're using the same public key we use while communicating with all our peers.
We should refactor to have an execution flow like the following one:
whatever.com/b3e2757a-d31f-41f7-ba3b-d0d18fd2fd46
Adapt UI size to mobile and tablet clients. Right now it's too small, and it allows to zoom-in and out.
Detected in #40
After setting display name WebRTC connection is being lost, and for that reason the name disappears for some seconds.
In fact, if you closely look at the 13th second of the video, you'll see how the Anonymous text is firstly replaced by the new nickname guest and after that, it disappear for ~10 seconds.
https://monosnap.com/file/la0NldV5KwAmETRiYsVv5642kM0oSV
When a new version of P2P Editor is deployed, changes are not visible until the browser's cache is cleared.
This is happening beacuse the name of the static files (main.js
, main.css
, etc.) is not modified in each new version.
With the current session storage (RAM) when the user reloads the page the session is lost. This is also a problem for development, because session is lost for each code change due to webpack dev server hot reload.
Here are listed web storage available options.
All write operations are performed by the peer initiating the session:
We have some features that need all peers to be able to perform write operation like:
Allow write operation to all peers:
In summary, each peer has a write hypercore DB and a read hypercore DB for each connected peer.
In this architecture, when a peer performs an action that wants to publish (for example: CHANGE_DISPLAY_NAME action), he/she simply store the action in its own DB. This action will be recieved by all peers by replication, and they will react to this action.
After a lot of try, error and documentation, I have a working prototype of this architecture that uses WebRTC datachannel, that we can translate to P2P Editor.
This architecture can be plugged easily with Redux and any frontend framework like React and Vue.
README.md
sections (##
)He have several dependencies with known security vulnerabilities.
Would require the dependencies upgrade process modifications on our end due to public API changes? Or would it be something painless? ๐ผ
When a user opens P2P Editor in a browser that does not have WebRTC support, we need to tell him/her to upgrade his/her browser.
P2P Editor can't run in your browser ๐
Please, upgrade your browser or try it in another one.
webrtc-swarm has a property for checking if browser supports WebRTC https://github.com/mafintosh/webrtc-swarm#swarmwebrtc_support
Browser support:
Add more "P2P eXperience" features:
Blocks: #8
Current Dockerfile implementation is designed for production environments. Replace it with one for development.
The application is gaining traction in terms of stabilizing the codebase and we're close to the 1.0 milestone. Congrats! ๐ฌ๐
Because of that, I think we should do something in order to avoid losing the trace between issues and their corresponding changeset (Example: issue - changes) ๐ผ
I understand that we're still in a very early stage of the application and we need to bootstrap the skeleton modifying a lot of times the very same lines of code.
If we apply a classic Pull Requests workflow (waiting for PR review and so on), we could make the experience a bit frustrating:
Even if we could workaround that, for instance, concatenating PRs opening them based on the previous one; it could end up also being frustrating because of requesting changes on the first PR of the chain would make to apply it rebasing or merging all the concatenated PRs branches.
For this reason, I would suggest to open a PR per issue even if we don't block the PR merge. That is, we wouldn't have to wait for a PR approval in order to merge it.
This way we'll only modify master
through PRs merge commits (not pushing commits directly to it). That leads to exposing the different changes we're making (so anyone can actually see why we're making those changes), and be able to trace when and how an issue has been solved.
Furthermore, we'll allow to let anyone review the change set made due to a specific issue and provide feedback even if it has already been merged.
What do you think?
This will be the base feature in order to let us add further features in the next Milestones.
localhost:8338/0d69a7c0-e04d-4ffd-9490-f4901a0bdeba
)๐ Use already available JS libraries in order to communicate using WebRTC or WebSockets. We could keep the high level abstraction by the moment in order to simplify the project bootstrap
Setup ESLint in order to maintain a consistent JavaScript code style.
Detailed comparision:
https://medium.com/@uistephen/style-guides-for-linting-ecmascript-2015-eslint-common-google-airbnb-6c25fd3dff0
Best known code styles:
Allow to select a user from the connected users list and follow him/her
That is:
From #40
When a second user opens the same session but before he introduces its nickname, it appears in the Users list as Anonymous. This could be confusing for the users already in the session because they could think that someone has joined and can actually see the contents of it (something not true yet).
However, I wouldn't vote for changing this behaviour grimacing. Instead, I would go for leaving the user land right in the editor of an existing session and letting him edit his preferences afterwards. That is, not asking his nickname before joining the session. The main reason would be to reduce the friction with the user to the bare minimum while joining a session. This is something similar to what http://zoom.us does while joining an existing conference session
If we go for this approach, it'll be definitely useful to list new session joiners as Anonymous until they set their nickname slightly_smiling_face
Other users should be able to click on an "Open external session" button in order to introduce a session ID and connect to it
In order to improve development experience setup webpack-dev-server
Didn't we changed the default port to something more random to avoid collisions with common local development environments?
Suggested port: 3617 (the closest numbers to the edit word I can think of right now xD)
This would imply also:
Add a button in the UI in order to let the user save a snapshot of the current code as a GitHub Gist.
This way, we could do a future feature in order to start a session from a previously saved Gist.
In order to modify configuration between different environments / installations, setup dotenv.
Replace hardcoded values with:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.