|
So I'm going through a phase of being ridiculously sold on Elm and wanting to try something non trivial in it. Seriously watch Evan's Lets be Mainstream talk, it's amazing to see a young language in the front end with responsible management, ensuring you can actually rely on packages, coding style, etc etc. The foundation of the elm architecture is great too. I had one question though that maybe fart simpson could help me with. With the StartApp package it has a way to send in inputs and map them to actions for the model. Do components have any way to request Signals themselves, as I can see cases where you'd have say a Draggable component, and that'd like to listen to the Mouse.position signal once you start dragging, or a timer listening to (Time.every Time.millisecond). All that said though, the animation example nearly gets there with Effects.tick. You're element is always going to know whether it needs to be reading from a signal, with a Draggable it would have a state of Dragging so it knows to trigger an effect at that point, so I guess all I'd be looking for is a way to make a Signal be polled by a Task that you can map into an effect. Does this seem reasonable? If it's at all possible to collect from a Signal with a task then you can keep the Static Signals, yet only be turning them into actions when actually required, keeping the possible complications down of polling say the Mouse position continuously. I guess what I'm looking for is just something that can do (Signal a -> Task Never a) and then if be golden. Elm could do with a Hoogle-like.
|
#
¿
Dec 20, 2015 09:33
|
|
|
|
| # ¿ Apr 29, 2024 11:49 |
|
|
By the looks of it it's just missing a decent package. Routing in web apps is pretty straightforward if you know how to go about it, with something that can map paths to a Route Type with parameters. You'd need to write Native bindings to do it properly in Elm though, so you can bind to the various page change events.
|
|
#
¿
Dec 21, 2015 07:01
|
|
|
From what I see he's not ignoring it, but trying to get away without it for as long as possible to avoid bloating the language. Feels reasonable, and there's nothing saying it won't ever get implemented. I think it's a good thing that every feature will have to earn its spot, although I agree that typeclasses are kinda important. When I tried doing a typeclass style approach in Scala ( having played a lot with Haskell beforehand ) I realised just how much of a boon a good implementation of typeclasses is for cutting down on boilerplate. Unfortunately trying it in Scala, while possible, just feels nothing like it.
|
|
#
¿
Dec 31, 2015 03:51
|
|
|
Considering in JavaScript land object literals get used as containers for absolutely everything, I think a good record syntax with extensibility and type checking makes a lot of sense, given the target audience and domain.
|
|
#
¿
Dec 31, 2015 04:14
|
|
|
fart simpson posted:
Im not concerned about the performance, more just good encapsulation. Generally when you mousedown on something Draggable you want to track the init position, and then poll mouse movements globally until mouseup. It'd be nice to encapsulate that as an effect that's just a task that gets the next notify call of a signal (and possibly combines signals if you needed to). That way the signals stay static, and the signal -> task can be mapped to actions specific to the component rather than being passed down from StartApp.
|
|
#
¿
Jan 10, 2016 00:54
|
|
|
fart simpson posted:The real answer here is that this is type of thing is an ongoing discussion in the Elm community. There's people talking about wanting ore encapsulation like you describe, and there's other people talking about how they like how explicityly modeled everything is, and all that's really needed is something to reduce some of the boilerplate. I'm not sure what I think about all of it, but I kind of lean toward not thinking something like the Signal a -> Task Never a function would be a good thing. I find the more I work with the Elm Architecture and explicitly passing things down the hierarchy the more I appreciate how explicit everything is, and it makes stuff like more traditional components feel like a tricky implicitness. Like in your example, the Mouse position is an input that's needed to compute the full state of your program, isn't it? The problem with explicitly passing things down the hierarchy is that at a point you're preventing code reuse, because as per the architecture Actions are what get passed down, you could never write a nice module for Drag and Drop without boilerplate from outside to convert whatever the mouse input signal is to to the Drag and Drop's expected actions. Maybe I just need to try another tack with this, but I just feel like it blocks off the kind of stuff I do with React components that can keep complex interaction code confined to the component in concern with a simple API that requires no internal knowledge.
|
|
#
¿
Jan 11, 2016 21:33
|
|
|
Effects is only necessary if you have Actions which kick off tasks (that then map to Actions) Always on signals don't need that.
|
|
#
¿
Jan 16, 2016 09:15
|
|
|
Elm does a pretty good job of dumbing it down for front end developers, so maybe the code examples and guides there provide some good practical examples of frp
|
|
#
¿
Apr 21, 2016 00:36
|
|
|
It would work just fine, there's absolutely no reason you NEED to put CSS in the markup, they're just demonstrating from a do it all in Elm Standpoint. Just use CSS classes instead, write BEM style components.
|
|
#
¿
Apr 28, 2016 22:14
|
|
|
Working in React & Redux is similar but clunky because JavaScript doesn't have first class support for its base principles (immutability and FRP) like Elm does. The plus side is it's easier to write 'escape hatch' imperative code for pragmatism reasons, although of course if there was less friction to doing things right like in Elm, you'd need the escape hatches less.
|
|
#
¿
Apr 30, 2016 23:50
|
|
|
xtal posted:99.999% of UIs are that trivial and if you think you're the exception you're probably wrong but knock yourself out The amount of contempt that you have for front end development shows that maybe you shouldn't be weighing in too heavily on it man.
|
|
#
¿
Nov 28, 2016 23:50
|
|
|
I want to look into erlang or elixir for web development, after having a lot of experience with Python. My main usage will be building stuff bigger than the stuff I use Django for, so essentially I want to figure out the OTP stuff so I can make good use of the hardware I have with at least security in the knowledge that scaling won't be so bad as splitting up a monolith. What's best in breed in the ecosystem according to people who actually use erlang/elixir? What am I losing if I use elixir? All the frameworks out there market themselves exactly the same way saying they have a great dev experience or fault tolerant or whatever, all products of the language largely, so it's hard to tell where's the best place to invest my time in first.
|
|
#
¿
Feb 4, 2017 21:38
|
|
|
|
| # ¿ Apr 29, 2024 11:49 |
|
|
Already looking through Monoqnc's book on erlang, so no doubt I'll be getting used to both syntaxes while I work through it, just not the type of person with the time or inclination to slowly work through an entire book, I'd rather be applying the knowledge to a project and jumping back and forth between learning and doing. I guess Phoenix is where to carry on with that.
|
|
#
¿
Feb 4, 2017 23:45
|
|