#elixir-lang - 26 June 2019
« Back 1 day Forward 1 day »
[07:41:59] serafeim: is anybody familiar with email protocol internals ? if not where (which channel) should i ask ?
[11:29:11] dysfun: anyone have a good recommendation for one of those css libraries that doesn't use classes that just makes basic html look less terrible?
[11:35:24] dysfun: remember the names of any? i searched 'css' and predictably there's tons of stuff
[11:37:39] dysfun: lol this turned up. didn't read but the title is amusing https://css-tricks.com/how-to-increase-your-page-size-by-1500-with-webpack-and-vue/
[11:39:41] serafeim: no... and unfurtunatelly although milligram *does* have classes it's missing a lot of things
[11:40:25] serafeim: but I've had variosu problems with milligram, here's one for example : https://github.com/milligram/milligram/issues/227
[11:42:14] sevenseacat: well phoenix only needed styling for its welcome page, and bootstrap was total overkill for that
[11:42:39] serafeim: sevenseacat: well no i think that phoenix also needs styling for the gen.html pages
[11:43:55] serafeim: sevenseacat: ha ha ha why is that ? i actually use that stylesheet (milligram) in my project: https://github.com/spapas/phxcrd
[11:44:32] sevenseacat: sure, you can use it as a base, but any real app is going to need a lot more design work than it can give you
[11:52:08] serafeim: serafeim: however i think that bootstrap4 already has a bunch of utility classes: https://getbootstrap.com/docs/4.3/utilities/borders/
[11:53:11] serafeim: i use the utility classes of bootstrap4 (like mb-2, pt-3 etc) all the time. i've even replicated some of them in my milligram based project: https://github.com/spapas/phxcrd/blob/master/priv/static/css/phoenix.css#L121
[11:53:42] serafeim: dysfun: i really recommend using the utility classes of bs4 i mentioned (i think bs3 lacks them)
[11:54:21] dysfun: yeah the problem is i've been burnt a lot by css frameworks and the buyin they require and the fixes you have to make to your own stuff to cope with them
[11:55:38] serafeim: dysfun: i agree. the good thing is that most of the things i develop don't need too much design (they are apps for internal users of my org)
[12:03:23] benwilson512: particularly if you end up using live view which doesn't interact very well with bootstrap's js bits
[12:06:30] dysfun: backend generating frontend for js framework that knows nothing at all of backend but will be impacted by tons of updates from it
[12:08:09] benwilson512: not sure I follow, bulma doesn't know or care about live view and vice versa
[12:13:49] nox: benwilson512: Just make a new browser that makes DOM mutations not an issue anymore obviously.
[12:14:52] benwilson512: since it detects a difference between the current dom state and the dom state it's being told to make happen
[12:15:48] nox: benwilson512: I'm jesting but the fact that we have entire frameworks and libs with their own overhead to batch DOM mutations to make them less painful is nuts to me.
[12:16:34] benwilson512: nox: well, even if the browser had a built in "make it so" function this issue would remain
[12:17:01] nox: benwilson512: No, we need better dynamic layout engines with better use of parallelism.
[12:17:35] benwilson512: as long as there is an entity that claims to know what the entire dom state should be, it will conflict with some other entity that's making out of band changes
[12:19:06] benwilson512: if jquery says "don't hide this" and phoenix says "hide this" it's gonna stutter
[12:19:36] nox: I'm not talking about that, I'm talking about things like React existing at all mostly because of perceived slowness in the browser's DOM APIs.
[12:20:51] nox: benwilson512: I may be arguing to procrastinate from implementing floats and margin collapsing. :P
[14:15:09] josevalim: mitchellhenke: it seems that phoenix_pubsub_redis does not implement direct_broadcast and instead it just broadcasts to everyone
[14:32:50] hypercore: hey guys, how can i order a has_many relationship? e.g. if i want to render <%= for article <- @user.articles do %> and i want the articles to be order by newest first
[14:34:12] hypercore: is there a concise way of doing this (that's not passing a seperate "@articles |> order_by" variable in my render function?
[15:00:51] josevalim: mitchellhenke: done :) the phoenix pubsub v2.0 api is much simpler to implement
[15:03:19] josevalim: i mean, it does allow custom fastlaning, but i think only a handful of people need it
[15:32:54] jeregrine: gamache: you were right, the other day I was being a jerk. thanks for calling me out.
[15:33:25] ankhers: The socket has a :private key with what looks like assigns from my conn. Is there some public API to retrieve those values? Or is it safe to access the :private key?
[15:39:24] ankhers: The user that is logged in so that I can verify they are allowed to do the thing they are trying to do.
[15:41:27] ankhers: Yes, but I don't really have access to the user without accessing the :private key.
[15:42:00] ankhers: So I just want to make sure that it is safe to do so, or if there is something I do not know about.
[15:43:12] ankhers: No. I rolled my own because nothing was really big when I started on this project. But I am using a live route, which does not hit a controller, so I do not have access to the conn before I get the socket.
[15:45:12] ankhers: But like I said, all of my conns assigns are under the :private key of the socket. I'm assuming it is relatively safe to access that?
[15:47:26] Zarathu: but probably the best thing here is to just use a controller to provide session data to the live view's mount/2
[15:47:56] Zarathu: or if you can get away with it, just having an authentication plug in your router that checks to make sure the user is authenticated
[15:48:01] ankhers: Yeah, I just thought that was unecessary complication and indirection with something relatively simple.
[15:48:48] ankhers: It isn't in the view though. It is in the socket side of things, which I see more equivalent to the controller.
[15:50:40] Zarathu: the logic for handling unauthenticated users, is it the same across all or most of your live views?
[15:50:45] ankhers: Also, I do have a plug that ensures they are logged in, but not one to ensure they are only accessing resources they should be.
[15:51:45] Zarathu: yeah, if you need to access conn data the only way to do that is in a controller. i wouldn't access :private for that. it might be more complicated, but less "dirty"
[15:53:20] Zarathu: "the socket side of things, which I see more equivalent to the controller." - a socket is not a controller. :p
[15:55:40] Zarathu: benwilson512: i remember thinking from last time we had this discussion, it would be really nice if `conn` was made accessible to the live view via some callback
[15:56:51] benwilson512: well you wouldn't want to embed the whole thing in the page, you'd need to encrypt it at least
[15:56:57] ankhers: I don't think the entire conn needs to be accessible. But having a safe way to access my assigns would be nice.
[15:57:37] benwilson512: nobody tailors their assigns to be optimized for transfer to the client and back
[15:58:03] Zarathu: ah right. at least, there should be documentation helping people decide between a live route vs. using a controller
[15:58:39] benwilson512: the first render _is_ done as part of an HTTP request, but then the subsequent live render is not
[15:59:15] ankhers: Sure, but if I needed to continue using them, I could just throw them in the sockets assigns.
[16:00:59] benwilson512: Ankhers: it always needs them in the live render so that it can diff it against the current dom state
[16:03:25] ankhers: "When a LiveView is mounted in a disconnected state, the Plug.Conn assigns will be available for reference via `assign_new/3`, allowing assigns to be shared for the initial HTTP request." -- https://github.com/phoenixframework/phoenix_live_view/blob/9fcff9666f9fb2a6ea6c5081aa0899a3cd8f636f/lib/phoenix_live_view.ex#L731. It sounds like I should have access to them.
[16:06:58] ankhers: I guess I will just use a controller for this. Still seems unnecessarily complex and indirect to me.
[16:09:27] benwilson512: unless I've got my mental model wrong, every request is _two_ requests. An HTTP request that loads all the data and renders, and then an entirely separate websocket request that needs to do the same thing
[16:19:50] benwilson512: there's no fundamental difference, just a different medium, and consequently fewer people
[21:08:19] Poeticode: so I made a prod release with distillery. version 0.1.6. I unzipped the resulting app_name.tar.gz to a new directory, and started the app. later, I made a prod release with the --upgrade flag, version 0.1.7. I moved that over to the releases folder in that new directory. But now when I run `bin/app_name upgrade 0.1.7`, it complains that it can't fi