redrabbit
commented
5 years ago After experimenting with Phoenix.LiveView, I don't think this is the right thing for this project.
We rely on Javascript for a few things:
- basic UX components (
<Search />,<UserInput />, color picker, etc.). - complex UX components with real-time support (
<Issue />,<CommitReview />, etc.). - faster rendering (offloading async requests tot the client).
I see what cool things people have been creating with it but I don't think it would be provide any benefits for most of our uses-cases.
Our current JS stack is based on React and Relay. GitGud.Web.ReactComponents makes it very easy to render React components by passing a list of props. Having a bunch of React components and various hooks executed when the DOM is ready is also quite handy.
Most of the time, we don't need to keep an open connection to the server and pass data around.
With the exceptions of <Issue /> which is the most complex component so far (using Phoenix.Presence and GraphQL subscriptions over Phoenix.Channel) and <CommitReview /> (using GraphQL subscriptions as well).
Our GraphQL backend provides support for subscriptions which covers our needs quite well so far.
Now there are a few things that would be really nice with Phoenix.LiveView (such as client-side form validation) but I don't thing it worse the effort.
We have started the
liveviewbranch a while ago for this purpose.Phoenix.LiveViewis still very experimental. Currently, our React/Relay implementation performs better (no need to double-fetch resources) and feels less cumbersome.Here's a list of React component to rewrite:
<Search />- Global search component.<UserInput />- Form input for adding repository maintainers.<BranchSelect />- Repository branch/tag select dropdown.<CloneDropdown />- Repository clone dropdown.<Comment />and<CommentForm />- Markdown comment threads.<CommitReview />and<CommitLineReview />- Commit reviews.