dailydotdev
🐛 BUG: markdown rendering gone awry
What went wrong? 🤔
What happened here, guys?
https://app.daily.dev/posts/i-went-deep-and-wrote-a-fairly-detailed-proposal-for-typed-array-in-php-php-function-processuse-rxnr7fvvb
This looked fine when I previewed it, when I posted it last night.
Expected Behavior
Markdown rendering correctly 😁
Steps to Reproduce Issue
1. Open the link
Solution Proposed
No response
Screenshots
No response
Environment
No response
Browsers
Other
OS
Android
Version of daily.dev
browser
Additional Context
I'm using Vivaldi on Android
I wrote the post from a Windows desktop with Chrome last night though
Code of Conduct
- [X] I follow the conditions of this project.
Uh, it gets weirder still.
I pressed "edit", and immediately the post shows up as correct markdown, and the preview tab looks correct.
I then press "save", and it doesn't even confirm saving, it just takes me to some other page??
I go back to the post, and it still looks broken.
Is there something in my markdown or something it just doesn't "like" about that post?? 😅
Are you client-side rendering the markdown or something?
I noticed here's a split-second after a hard page reload (CTRL+SHIFT+R) where the markdown flashes in with white space:
It then removes all the white space but doesn't render the markdown. 🤷♂️
It's beginning to smell like some React-ish SSR thing gone wrong? 😅
For the record, I already tried disabling all browser plugins while editing/saving, same deal. I don't think this is a "me" problem.
Hello @mindplay-dk have you ensure the opening triple backticks and closing triple backticks are on separate lines with no extra spaces or content ? because everything works correctly in my side
Hello @mindplay-dk have you ensure the opening triple backticks and closing triple backticks are on separate lines with no extra spaces or content ?
yes - here is the content, verbatim:
I went deep and wrote a fairly detailed proposal for typed array in PHP.
```php
function processUserConsent(bool $accepted, array<string> $categories) {
if ($accepted) {
setcookie('consent', implode(",", $categories), time() + 24*60*60*365);
} else {
setcookie('consent', '', 1);
}
}
$post = [
"accepted" => true,
"categories" => ["necessary", "preferences"]
];
processUserConsent(...$post);
```
This is a very basic example, but the proposal considers many implementation details, backwards compatibility, future optimization, and features like reflection and references.
This looks like generics, and in a sense, it is - but for arrays only. It is designed to be compatible with a possible future generics feature (another proposal I worked on in depth previously) however it attempts to start with a much smaller feature, since the implementation details likely wouldn't overlap considerably with full-blown generics.
Note that this is a very different proposal from the [rejected 2014 proposal](https://wiki.php.net/rfc/arrayof) (both in terms of syntax and scope) and attempts to address most of the critique I could find in the mailing list activity from back then.
I hope this is enough to restart the conversation and motivate the community to reconsider this feature. 🙂✌️
as said, the preview tab looks correct as well - so this is valid markdown, as you can see here:
because everything works correctly in my side !
so I don't know what you did there, but that does not look correct? all the line breaks in the code block were removed.
it looks correct on my side though, as you can see from the screenshot above 🙂
are you using different markdown parsers/renderers on the client and server side?
perhaps your server side markdown parser/renderer is not doing a very good job. 🤐
Hi @mindplay-dk,
We have an inconsistency there that needs to be fixed. Our shared post doesn't support markdown even though the editor shows it does. We will think about how to solve it correctly
Our shared post doesn't support markdown even though the editor shows it does.
?!?! 😅
okay, that is a bit of an oversight ☺️
it's already a pretty great site though - I feel like this is what dev.to was supposed to become but didn't 😉
uhm, so in my latest post, I intentionally tried to avoid markdown and... it was rendered as markdown 🤷♂️
https://app.daily.dev/posts/first-draft-a-check-operator-for-php-1o1jtwa51
did you change something already?
@mindplay-dk this is not a shared post.
Shared post are when you share a link via the view. When you just use the freeform typer you can use markdown.
@mindplay-dk this is not a shared post.
Shared post are when you share a link via the view.
wow, that is really confusing. 😅
I'm guessing you referenced this from Reddit?
this feature always confused me on Reddit as well, and I'm honestly not sure they have the recipe for good UX here. 🤔
I'm not even aware of having done two different things when creating these two posts - I guess, the first time, I must have thought "I'm posting a link", saw the button and switched... and the second time, I didn't even notice the option was there.
I would suggest to back up and ask, why are posts and links are treated as two different things?
Similarly to Reddit, you do your best to conceal the fact that there are two different types of posts, when they're presented in the feed - which should beg the question, why are we asking the user to make this choice, and then trying to erase the difference?
At least you had the good sense to include the comment input for links, unlike Reddit - this further points to your having already noticed that there's a problem with the UX on Reddit, and decided to do something about it. But it makes the difference between these two types of posts even more insignificant - and confusing.
Is there any reason not to have just one form, where the link is optional? 🙂
Actually, in our case, it has to do with some technical constraints that create this separation. Fixing it is not as easy as one may think. But we will consider streamlining to process. Your feedback is valid