For me, inertiajs is about being able to swap out front end and backend frameworks with a common protocol.
kanishka
hansihe
I want to throw my project into the arena here as well. Confusingly it’s also called LiveData, but uses a quite different approach from a lot of other projects I have seen.
LiveData has a concept of tracked functions, defined with deft instead of a regular def. When compiling deft functions, they are transformed in a way which extracts static chunks of the data structure and sends them only once. Instead of a general tree diff, it draws inspiration from virtual dom frontend frameworks and enable you to specify keys/IDs for subtrees which enables the runtime to efficiently generate diffs for you.
deft render(assigns) do
%{
posts: for post <- assigns.posts do
keyed post.id do
%{
id: post.id,
title: post.title,
content: post.content,
}
end
end
}
end
This is how the render function could look like in a LiveData. Other than this, things look pretty much exactly like a LiveView.
Here, keyed is used to specify an a key that can uniquely identify the post. By doing this you get the following advantages:
- If a post changes, only the change in that post is ever sent.
- No static content is sent twice, the
postskey,contentkey + more in the map is static, so is only sent once at the beginning of the connection. - If a post is added, only the added post is sent.
It’s not very cleaned up, but here is a simple example of a LiveView: phoenix_data_view_demo/pdv_backend/lib/pdv_backend_web/hello_world_data.ex at main · hansihe/phoenix_data_view_demo · GitHub
https://github.com/hansihe/live_data
6
hubertlepicki
What can I say, great minds think alike 
But it’s both validating and encouraging that this is not just me N=1 thinking about this. Also, many different projects may result in fragmentation with no clear choice for users, temporarily, but we probably don’t need a dozen of different solution but 2 or 3 slightly different ones.
1
Sebb
addstar
@superchris I’m having a play around with your library live_state and am really liking it. I’m using it with lit and your decorators. Whats your approach to handling errors? I’m thinking of 2 different types of errors; expected errors like changeset errors and unexpected errors like if you have a case statement with a catch all.
0
superchris
Great question! For actual errors (socket or channel failures for example) I’m underway with adding support for an error event from LiveState and added an issue to track it here: Error handling · Issue #5 · launchscout/live_state · GitHub. I have an initial implementation, but am not entirely happy with what I came up with and want to rework it a little.
For changeset “errors” (really validation failures) my thought is those belong on state. I put together a CRUD example recently to show how this could work, I need to figure out where to put it. With the amount of subprojects, examples and related things it might be time for a livestate github org. For now, I created an issue so I can remember to do this: CRUD example · Issue #6 · launchscout/live_state · GitHub
2
maxmannen
Thrilled about this…
I have started to look in to Sveltekit (1.0 now) with a Phoenix backend. This could the bridge between this great programming tools.
I there a NPM package for the client side of Svelte? I can find your examples but it seems you include packages that are local on your server? I am not up to speed on Svelte so might miss something.
Anyway, Phoenix/LiveData/Sveltekit (with Skeleton UI) looks like a really nice way forward for me.
0