2¢: I could get behind “plain view”
ChristianAlexander
ashrafhasson
“The beginning of wisdom is to call things by their proper name.”
― Confucius
I must say, the term DeadView did certainly introduce a confusion when I first encountered it somewhere and the reference implied wasn’t immediately obvious to me. The problem wasn’t that it is used but rather that it was not used in the official docs 
To me, it feels totally fine to have View and LiveView but if the community wants to rename View to something else, maybe consider making a reference to that rename occurrence distinctively obvious and well documented to avoid panic attacks 
Using one type over the other isn’t even a standard nowadays from what I’ve seen and thus I see no “perfect” new name for the original View 
Thanks for the discussion though.
1
ErikNaslund
-
I’d really like getting an endorsed name for non-LiveViews. It helps a lot when googling for stuff, and when talking to other developers. I care less what the name actually is.
-
Just calling the non-live one just
Viewdoesn’t quite do the trick for me. It’s like having “LargeCat” and “SmallCat”, but for some reason referring to “LargeCat” as just “Cat” in everyday language. They’re distinct, and none of them are any “more cat” than the other . (</end of already halting cat analogy>) -
I get easily confused, more so than some people I think. When you are talking about DeadViews and LiveViews, what specifically do you mean?
In the current Phoenix docs there’s this:
However, most commonly controllers invoke custom modules called views.
Now, when invoking render/3, a controller named MyAppWeb.UserController will invoke MyAppWeb.UserHTML and MyAppWeb.UserJSON respectively when rendering each format.
In this particular case the “View” the docs are talking about is the *HTML module. Normally when I think about DeadView vs LiveView I think about the “whole thing”. This makes it even weirder because now I have to say “a DeadView View” when I talk about the *HTML module 
-
I lean towards something similar to what @olivermt suggested. Maybe
OneShot View, even though it’s a bit wordy. My thinking is that the LiveView keeps a live websocket connection, whereas with the OneShot View you very much render and forget (from a server side p.o.v.). That naming kinda reflects their difference in behavior. I don’t love this suggestion myself, but it’s the best I can think of…and I like it more than DeadView -
I’m positive that this has been asked a million times before, but I can’t find any good details about it - would it be possible to somehow, to some extent, unify how DeadViews and LiveViews are written? If anyone has a pointer to a forum post or something that deals with this I’d love to read that!
One of the few things I dislike about Phoenix is that I have to make the choice between LiveView and DeadView when I start creating a new page, and it’s a bit of work “switching” from a DeadView to a LiveView later on once I realize that I need it. I also need to understand and remember both the DeadView and LiveView way of doing certain things. There’s also the fact that when I’m writing helper functions I need to think about a lot more things like “am I receiving a conn or a socket here”, to be able to support both DeadView and LiveView. My ideal Phoenix incarnation would only have
View, and it would be most similar to what we currently call LiveViewCould we have a LiveView that could be told to not perform the websocket connection for example? (just as a silly idea). I’m sure a lot of people have considered the plausability of this…and I’d love to read more about it!
Thanks for bringing up the issue @BartOtten. I think it’s definitely one worth fixing. As a dev who’s relatively new to Phoenix it took me waaaay longer than I’d like to admit before I had worked through the naming confusion and understood what was what in the Elixir/Phoenix world
(Sorry for the wall of text)
3
derek-zhou
You mean LiveView and View, right?
I actually like it this way. My applications are either 95%+ pure LiveView or 95%+ pure View; my brain does not work well if I have to mix and match on the fly. So, I take some time to make a call before writing the first line of code. I consider it time well spent.
2
KP123
ErikNaslund
Haha, sure, I mean LiveView and View
I completely get what you mean about taking the time to decide if the view should be live or not before going ahead with the implementation. I do the exact same thing, and usually it works well.
However, I have been found guilty of being too lazy to “promote” a view to being Live, because of added functionality / requirement changes. Instead I’ve hacked on a form with a POST, felt a bit of shame, and moved on 
I have a couple of pages like that, because even though they made sense as View with the initial requirements, I would 100% rewrite them using LiveView now knowing how they evolved.
0
derek-zhou
I am not sure you do. I meant to keep the whole application pure View or pure LiveView; not just individual pages.
I don’t see anything wrong with old school form with POST, if it work the same way everywhere in your application. In UI design, consistency trump flashiness. If the user input does not pass validation, you still can re-render the form and pointing out the problem using plain View, so no functionality is lost.
0
AndyL
kernel
Apologies if this comes across a bit too frankly, but I think this is an terrible proposal, surely there are more important things to focus on.
3
ken-kost
Sometimes you focus really hard on a problem, you spend all your mental juices and then you need a break, a recharge. Something light, trivial, but close to heart. Something like naming conventions. So you jump into an active discussion in the community about such trivialities. A worthy distraction I would say; it beats tik tok in any case. 
5