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

Real-time #36

Closed
brillout opened this issue Oct 1, 2022 · 5 comments
Closed

Real-time #36

brillout opened this issue Oct 1, 2022 · 5 comments

Comments

@brillout
Copy link
Owner

brillout commented Oct 1, 2022

The idea is to create a new library called Televar that works independently of Telefunc.

Because I don't think functions are the right approach for real-time. Instead Televar uses "remote variables" that are automatically synchronized.

This is a much more natural approach: when you think about it, real-time fundamentally is about synchronization of information.

@brillout
Copy link
Owner Author

brillout commented Oct 1, 2022

CC @louwers @nitedani

@brillout
Copy link
Owner Author

brillout commented Oct 1, 2022

This is low-priority on my side, but I'd be up to co-create this, in case someone is up for it.

@nitedani
Copy link

nitedani commented Oct 1, 2022

I don't see the advantage of variables over functions, but I think that is because I don't know what you have in mind. How would reactive code look like using variables? How would I know when the value of a variable has changed in the browser? Would the variable itself be converted to an observable when imported in the browser? Would we export utility functions to convert a variable to react state or similar? Somehow I would still need to tell the server to start sending me something(in this case messages), and for that I would still need an api call/telefunction.

For example, using functions it would look like this:

// server
export const getMessages = (cb) => {
    setInterval(()=>{
        cb('hello')
    }, 1000);
}


// browser
export const Messages = () => {
    const [messages, setMessages] = useState([]);
    useEffect(() => {
        getMessages((msg) => {
            setMessages([...messages, msg])
        });
    }, []);
    ...
}

Or like this:

// server
export const getMessages = () => {
    return new Observable(subscriber =>{
        setInterval(()=>{
            subscriber.next('hello')
        }, 1000);
    })
}


// browser
export const Messages = () => {
    const [messages, setMessages] = useState([]);
    useEffect(() => {
        getMessages().subscribe((message) => {
            setMessages([...messages, message]);
        });
    }, []);
    ...
} 

Using variables, it could look like this:
messagesVar could be stored on server,browser, or both. For example if it's stored only on the server side, then every access in the browser would need to be proxied to the server variable. If it's stored only in the browser, then every access from the server side would need to be proxied to the browser variable. If it's stored both sides, then only mutations need to be sent to the other side, and access can be local.

export const messagesVar = defineVar([])
export const getMessages = () => {
    setInterval(()=>{
        messagesVar.push('hello')
    }, 1000);
}

@redbar0n
Copy link
Contributor

@brillout
Copy link
Owner Author

using functions it would look like this:

I also thought about this, but I eventually found many problems about that approach.

Actually, thinking more about Televar, I found major limitations around designing everything around "remote variables".

So far, I can't find a design that fits every need.

Real-time needs differ highly depending on the use case. E.g. a chatroom a la discord has different requirements than a game with a single user-shared global state.

I think we should make Telefunc focused on RPC for now and postpone real-time support.

That said, I'd be more happy to have a look at a prototypes, if someone is up for designing and implementing a prototype.

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

No branches or pull requests

3 participants