Why do server cooties prevent post previews from rendering?
-
Reproduction steps:
- start typing a post or reply
- wait until server cooties
- modify the post in the editor
results: post preview pane doesn't update to reflect changes in post editor
expected results: post preview pane updates to reflect changes in post editordoes nodebb render post previews server-side??
-
I don't see any network requests while typing. What's more likely is that the JavaScript just hangs waiting to reconnect, I assume.
-
@bb36e i understand that there isn't really any reason to design a forum platform to be functional when the platform itself is down...i'm just curious if anyone has any insight as to why this happens (since I CBA to wait for cooties again)
-
@bb36e said in Why do server cooties prevent post previews from rendering?:
does nodebb render post previews server-side??
Yes, through the websocket connection.
-
@Tsaukpaetra Huh, Chrome's network and Timeline tabs don't at all track WebSockets (that I can see at a glance). That explains the delay for rendering.
-
@LB_ said in Why do server cooties prevent post previews from rendering?:
@Tsaukpaetra Huh, Chrome's network and Timeline tabs don't at all track WebSockets (that I can see at a glance).
Isn't it wonderful we have these awesome hipster technologies that are un-debuggable?
-
@Tsaukpaetra tbh i kind of understand the reasoning behind that implementation. why bother writing code to render posts for the server and client twice when you can write it once and have one call the other. but when it breaks it sucks.
-
@bb36e said in Why do server cooties prevent post previews from rendering?:
but when
itanything breaks it sucks.FTFY. It wouldn't be called a "break" if it didn't suck... ;)
-
@LB_ said in Why do server cooties prevent post previews from rendering?:
Chrome's network and Timeline tabs don't at all track WebSockets
It does track the websocket if you have the network tab open when it connects.
-
@bb36e said in Why do server cooties prevent post previews from rendering?:
tbh i kind of understand the reasoning behind that implementation. why bother writing code to render posts for the server and client twice when you can write it once and have one call the other.
Not to strain the server with sending a request to reparse the whole thing with each key pressed?
Besides, the forum software is JavaScript. The code is in JavaScript. Why can't it run on the browser if it's FUCKING JAAAAAAVASCRIPT.
-
Yeah, why can't their build process just copy the code into a string to be sent to the client?
-
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
It does track the websocket if you have the network tab open when it connects.
Norepro. It gets the 101 Switching Protocols response, but nothing when you type.
-
@Maciejasjmj true. ideally we wouldn't need previews. because you could tell what the post would look like without getting it rendered. but hey, that's the price we pay for using a markup language that's designed to be readable without being rendered.
[b]seriously, every time I use MD I get confused by how line breaks in quotes work[/b]
-
@Maciejasjmj are you sure you're on the right tab?
-
@bb36e said in Why do server cooties prevent post previews from rendering?:
why bother writing code to render posts for the server and client twice when you can write it once and have one call the other.
It's a shame nobody's figured out how to make Javascript run on the server so they can just run the same code in 2 different places.
...oh wait.
-
@Tsaukpaetra said in Why do server cooties prevent post previews from rendering?:
@LB_ said in Why do server cooties prevent post previews from rendering?:
@Tsaukpaetra Huh, Chrome's network and Timeline tabs don't at all track WebSockets (that I can see at a glance).
Isn't it wonderful we have these awesome hipster technologies that are un-debuggable?
QFMFT
-
@anotherusername remember how Discourse tried to do that and failed miserably?
In any case, the server has information that the client doesn't know that gets used to render the post.
-
@Maciejasjmj said in Why do server cooties prevent post previews from rendering?:
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
It does track the websocket if you have the network tab open when it connects.
Norepro. It gets the 101 Switching Protocols response, but nothing when you type.
Just run
localStorage.debug = '*';in the console. Obviously.
-
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
the server has information that the client doesn't know that gets used to render the post.
Secret sauce?
-
@anotherusername said in Why do server cooties prevent post previews from rendering?:
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
the server has information that the client doesn't know that gets used to render the post.
Secret sauce?
For example, the server has the source code for all of its plugins. It'd be strange to have to process iframely or emoji or mentions on the client. Plus all three of those are plugins, so NodeBB can't assume anything about how they work.
-
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
It'd be strange to have to process iframely or emoji or mentions on the client.
That's part of rendering the post, isn't it? Rendering the post client-side isn't strange. Hitting the server to render the post preview every time a key is pressed is strange. I bet @blakeyrat would have a field day if he knew about this.
-
@anotherusername sure, I'll just send the entire forum database to the client and have the client make arbitrary HTTP requests. That can't possibly have any downsides.
-
@LB_ said in Why do server cooties prevent post previews from rendering?:
Huh, Chrome's network and Timeline tabs don't at all track WebSockets
needs to be up before the ws loads (think F5) but......
green are frames sent, white are frames rec'd
-
@ben_lubar okay, granted, some things would have to be rendered server-side. But the client side should render as much as it can, and then fetch the stuff from the server that's actually required to be performed at the server. It's not like it'd be an annoying delay that we don't already have... there's already an annoying delay (and jellypotato) while humble links get magically transformed before my very eyes into glorious iframes.
I realize it'd probably be a total framework overhaul, (as in, since it wasn't designed from square 0 with this goal in mind, it couldn't be hacked into submission to do this without a complete rebuild), but a plugin that participates in post rendering could register JS shims that can run either server side or client side. If the plugin needs an interface that can only run server-side, e.g. like the part of the YouTube plugin which fetches video title and other information, it could also create a server-side interface for the JS shim to call asynchronously. It wouldn't necessarily need to hit the server every time it renders the post preview; it'd only have to hit the server when it actually needs the server to do something.
-
@bb36e said in Why do server cooties prevent post previews from rendering?:
does nodebb render post previews server-side??
Yes.
@Maciejasjmj said in Why do server cooties prevent post previews from rendering?:
Why can't it run on the browser if it's FUCKING JAAAAAAVASCRIPT.
Plugins. For instance, the youtube plugin, which requires a google API key. Maybe other similar things:
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
the server has information that the client doesn't know that gets used to render the post.
-
@boomzilla said in Why do server cooties prevent post previews from rendering?:
Plugins. For instance, the youtube plugin, which requires a google API key. Maybe other similar things:
Thought of that, and covered it in the post right above yours.
-
@anotherusername said in Why do server cooties prevent post previews from rendering?:
@boomzilla said in Why do server cooties prevent post previews from rendering?:
Plugins. For instance, the youtube plugin, which requires a google API key. Maybe other similar things:
Thought of that, and covered it in the post right above yours.
So instead of using the same code to render the post no matter what, you want the preview to be a hand-maintained copy of the logic used to render the final post.
That sounds like something, but I can't put my finger on it...
-
@ben_lubar said in Why do server cooties prevent post previews from rendering?:
That sounds like something, but I can't put my finger on it...
Cough Discoursistant!
-
@ben_lubar no... there'd be a JS function that's identical, and does the rendering on both the client (for the preview) and the server (for the submitted post), as far as possible on the client side. And regardless of where it's running, if it needed anything that had to be generated on the server side, it could call a server-side interface.
So the client-side runs the function, which calls the server-side interface only if it needs to. And the server-side run the same function, which also calls the interface if it needs to.
I.e. exactly the same code running on the client and the server, except the part which has to run on the server, which only runs on the server.
-
@anotherusername said in Why do server cooties prevent post previews from rendering?:
there'd be a JS function that's identical
How would an identical JS function know when to call out to the server or not, are you proposing some kind of transparent shim that the plugin would think it's talking to a function on the server's side but in fact actually isn't?
I'm a little confused, maybe I'm not visioning this properly...
-
@anotherusername said in Why do server cooties prevent post previews from rendering?:
Hitting the server to render the post preview every time a key is pressed is strange.
its required for detecting if anyone types candlejack before submitting
-
@Tsaukpaetra said in Why do server cooties prevent post previews from rendering?:
How would an identical JS function know when to call out to the server or not
Can it render the full contents on client side?
If yes: code to render the contents on client side.
If no: code to render as much of the contents on the client side as possible, and then XMLHttpRequest to the interface on the server that will return the remaining data it needs.
XMLHttpRequest should work equally well on either the client side or the server side, right?
Or it could call a helper function that is different on the client and server: on the client, it'd pass information to/from the server interface using XMLHttpRequest or the websocket; on the server it could pass information to/from the interface directly.
-
@anotherusername said in Why do server cooties prevent post previews from rendering?:
Can it render the full contents on client side?
Well, let's imagine that we came up with a way to do this. If the server is fuct you still can't post it.
-
@boomzilla yeah exactly, I wasn't looking for a fix for this or anything.
-
@bb36e It's a good question. People learn about the system based on it and the answers it generates.
-
@boomzilla said in Why do server cooties prevent post previews from rendering?:
@anotherusername said in Why do server cooties prevent post previews from rendering?:
Can it render the full contents on client side?
Well, let's imagine that we came up with a way to do this. If the server is fuct you still can't post it.
It'd provide a temporary element that'd be replaced when the asynchronous request returned, just like the onebox jellypotato we already know and love. If the server is down, you just wouldn't see it magically changing into the pretty.
-
@ben_lubar I'm sure @blakeyrat would be either pleased, annoyed, and/or horrified to learn you're learning his sense of hyperbole.
-
@FrostCat he is a nodejs dev now, I think he is serious
