|
|
|
|
|
|
by josevalim
1940 days ago
|
|
|
> The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket" Please Nick, you can literally check your links to see this is inaccurate. I mentioned a solution after the issue was closed - and not before as you describe. And I figured out the solution *with Chris*, as I clearly mention in my comment. And then later on: > dive into the source code that I can't read very well because there's a lot of macros There are like 8 macros... > since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time Seriously? No one has ever said this is the case. Just go to the [official docs](https://hexdocs.pm/phoenix_live_view). All public functions are properly documented, there are introductory guides, etc. Sure, we don't have official screencasts but that's something we rely on the community to step in: Pragmatic Studio has a fantastic course on LiveView (which I was involved as a sounding board), there is Grox.io, etc. And it hasn't stopped either, a new book was literally announced today. There are other inaccuracies in the comments below but honestly I don't have the energy to go down this rabbit hole again. |
|
|
I should have used quote / unquote instead of the word macro.
When I looked into the code I started with the engine and renderer. Between both modules they had dozens of quote / unquote usages which to me was hard to follow. Not because it's written poorly or anything like that, but it's not exactly easy to trace that code to learn how something works in more detail.
> I mentioned a solution after the issue was closed - and not before as you describe.
Yes, after it's been closed. But look at it from what end users of your library see from that chain of events:
1. User asks question on forums and presents a case where something very bad happens (2x network round trips)
2. User posts issue on GitHub
3. Creator of LV says it's a known trade off and quickly closes the issue
4. You and the creator of LV talk offline and figure out a potential work around
Re-opening the issue after #4 would have done a lot of good because it shows at a glance that it's a current issue, it's being addressed and open for discussion.
With the issue being and staying closed this gives off a message that you're not actively working on fixing the bug and aren't open to any form of discussion or assistance around fixing it. Maybe that wasn't your intention but that's the message you're sending to some people.
> Seriously?
That's the answer I've always received in the past when asking questions about the state of the docs on Slack and IRC over the years. The current docs usually give you a partial understanding of how something works. It's usually enough to get a basic idea of how something might work but not enough to get the ball rolling to implement a solution in your own application. I don't think I'm the only one who feels this way either because I've seen a lot of repeated questions on IRC and the forums, especially around LV components.