Re: [elm-discuss] Web components vs. Native

[Peter Damoc]

To my understanding there is no promotion of the web components as a
standard way of interacting with JS.
They are mentioned as a way of encapsulating complex JS that might fail.
In other words, one could use some complex widget (like google-maps) and
get some functionality into their elm app *fully aware* of the risks
involved.

1. Type safety:

There is none with web components BUT, you do get a nice border control and
black-box encapsulation from the perspective of Elm.
It very similar to using ports only that from my perspective, the
interaction is nicer.

2) Purity guarantees

You will be able to use a web component ONLY in the view will be as pure as
it is right now.
You will not be able to interrogate the web component, you will have to
subscribe to its events just like you subscribe to onClick on a button.
This is very different from Native that you can use all over the place.

3) Versioning guarantees

web components are not part of the Elm ecosystem and so, they are not and
will never be covered by elm-package. Maybe after we get the ability to
describe web-components in pure Elm, you will be able to find
web-components in elm-package.

So if the main motivation for discouraging the use of native is to promote
> safety, why encourage the use of web components?


Again, I don't think that the use of web components is encouraged.
They are only an escape hatch that is available to Elm programmers.

These being said, I do believe that the mechanism of web-components has a
lot to offer to Elm.

I have played with some prototypes and the experience of writing
web-components in Elm is quite lovely.
In an ideal world, we don't use  in Elm but rather 
becomes an Elm implemented web-component.
The web-component standard could be the official way to embed and interact
with Elm apps.






On Thu, Mar 23, 2017 at 1:57 AM, Maxwell Gurewitz 
wrote:

> Hi all.  I'm creating this thread to discuss the relative merits of web
> components and native code.
>
> It's my perception that web components are being promoted within the elm
> community as a standard means of javascript interop, while writing native
> code is discouraged.  In particular, Richard Feldman has recently added a
> section on web components to his book Elm in Action (great book btw, you
> should totally buy it!), and I'd love to get his feedback.
>
> I don't understand this preference for web components over native code.
> As far as I can tell web components and native code lack all of the same
> safety guarantees.
>
> 1) Type safety:
>
> Both native code, and js inside of custom web components have the
> potential to raise exceptions, or produce invalid results due to a lack of
> type safety.
>
> 2) Non-determinacy:
>
> Both native code and js inside of custom web components have the potential
> to introduce non-determinacy.  You can imagine that the google maps web
> component might receive a 500 status response from google during an outage,
> or the author of the component might simply include a Math.random.  This
> will violate the guarantees made by the elm-debugger which disables port
> code from running for exactly this reason, which could prevent you from
> being able to reliable replay UI interactions.
>
> 3) Versioning guarantees:
>
> Neither native code nor web components can be published in elm-package,
> and they both include javascript, so neither can benefit from elm's semver
> enforcement.
>
> Now I understand that web components may be more ergonomic than equivalent
> native code in certain situations e.g. in the google maps case, but they
> don't seem any more or less safe than native code.  Furthermore, they
> impose the cost of an additional build system (bower) and polyfills.
>
> So if the main motivation for discouraging the use of native is to promote
> safety, why encourage the use of web components?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

Hi all.  I'm creating this thread to discuss the relative merits of web 
components and native code.

It's my perception that web components are being promoted within the elm 
community as a standard means of javascript interop, while writing native 
code is discouraged.  In particular, Richard Feldman has recently added a 
section on web components to his book Elm in Action (great book btw, you 
should totally buy it!), and I'd love to get his feedback.

I don't understand this preference for web components over native code.  As 
far as I can tell web components and native code lack all of the same 
safety guarantees.

1) Type safety:

Both native code, and js inside of custom web components have the potential 
to raise exceptions, or produce invalid results due to a lack of type 
safety.

2) Non-determinacy:

Both native code and js inside of custom web components have the potential 
to introduce non-determinacy.  You can imagine that the google maps web 
component might receive a 500 status response from google during an outage, 
or the author of the component might simply include a Math.random.  This 
will violate the guarantees made by the elm-debugger which disables port 
code from running for exactly this reason, which could prevent you from 
being able to reliable replay UI interactions.

3) Versioning guarantees:

Neither native code nor web components can be published in elm-package, and 
they both include javascript, so neither can benefit from elm's semver 
enforcement.

Now I understand that web components may be more ergonomic than equivalent 
native code in certain situations e.g. in the google maps case, but they 
don't seem any more or less safe than native code.  Furthermore, they 
impose the cost of an additional build system (bower) and polyfills.

So if the main motivation for discouraging the use of native is to promote 
safety, why encourage the use of web components?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Embedding multiple elements into JS

[Matt Joiner]

I'm looking to embed Elm in an existing web application gradually. I find 
it most appropriate in my projects to embed multiple elements, not a single 
parent element. For example I have some bootstrap:



I want to run Elm.Main.embed(document.getElementById('some-list')), and 
have that main return multiple  elements. Clearly I can't have Elm 
return a parent  because then I have . I also can't 
have Elm return the  because 
then there's no #some-list to embed it on in the first place.

Look forward to suggestions, thanks.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

[Robert Walter]

Hi Richard,

this is not code that is in production yet and rather experimental, but I 
still think it might be worth sharing in the context of this thread since I 
had to write painful code to update nested records there (unfortunately, 
that code was never commited anywhere so I cannot share the ugly version, 
but I think you might be able to envision it given the model and the 
current code). I then came across an article by Wouter 

 addressing 
the topic of updating nested records and I tried to apply it to my use case.
Let's start with the model that represents a series of paragraphs and a 
text selection:

type alias Model =
{ paras : Dict Int Para
, selection : Maybe Selection
}
type alias Para =
{ text : String }
type alias Selection =
{ cursorCoordinate : TextCoordinate
, anchorCoordinate : TextCoordinate -- not in use yet
}
type alias TextCoordinate =
{ textPos : TextPosition
, location : Location
}
type alias TextPosition =
{ iPara : Int
, offset : Int
}
type Location
= Before
| After

I am aware that there is probably a lot of room for improvement for more 
experienced Elm developers, but here is the "best way" I could come up with 
for an update method that "moves" a selection to the left (think "arrow key 
left" is pressed by the user):

dismantle : TextCoordinate -> ( Int, Int, Location )
dismantle tc =
( tc.textPos.offset, tc.textPos.iPara, tc.location )

moveLeft : Model -> TextCoordinate -> Maybe Selection
moveLeft model ({ textPos } as cursorCoordinate) =
let
( offsetCur, iParaCur, locationCur ) =
dismantle cursorCoordinate

paraCur =
Dict.get iParaCur model.paras

cursorCoordinateNew =
case paraCur of
Nothing ->
-- this should never happen, since we should have a 
valid text coordinate at that point
cursorCoordinate

Just para ->
let
paraLength =
String.length para.text

iParaAbove =
iParaCur - 1

offsetNew =
(offsetCur - 1)
|> cropTo -1 (paraLength - 1)
in
if (offsetNew < 0) then
if (paraLength > 0 && locationCur == After) then
-- we moved "after -1st" character: 
normalize to "before 0st"
textPos
|> setOffset 0
|> asTextPosIn cursorCoordinate
|> setLocation Before
else
-- we moved "before -1st" character or we 
are in an empty para:
-- => normalize to "after last of prev. 
para"
let
mbParaAbove =
Dict.get iParaAbove model.paras
in
case mbParaAbove of
Nothing ->
textPos
|> setOffset 0
|> setIPara 0
|> asTextPosIn 
cursorCoordinate
|> setLocation Before

Just paraAbove ->
let
paraAboveLength =
String.length 
paraAbove.text

offsetAbove =
paraAboveLength |> 
cropTo 0 paraAboveLength
in
textPos
|> setOffset offsetAbove
|> setIPara iParaAbove
|> asTextPosIn 
cursorCoordinate
|> setLocation After
else
textPos
|> setOffset offsetNew
|> asTextPosIn cursorCoordinate
in
createSelection cursorCoordinateNew

To make this work, I've written the "set***" and "as***In" methods as 
Wouter suggests in his article to complement my "model-API": 

setSelection : Maybe Selection -> Model -> Model
setSelection selectionNew modelCur =
{ modelCur 

Re: [elm-discuss] Re: elm + reactive programming

[Răzvan Cosmin Rădulescu]

Sadly this debate seems to have ended :)

On Saturday, March 11, 2017 at 1:59:31 PM UTC+1, Răzvan Cosmin Rădulescu 
wrote:
>
> Interesting comparison, I need to check out this purescript some more. 
> Never heard of it before but it does look like there are libraries that 
> provide reactive functions or something, research time! Thanks :)
>
> On Friday, March 10, 2017 at 8:14:59 PM UTC+1, jphedley wrote:
>>
>> Here's a nice balanced Pros & Cons Analysis of JavaScript vs Elm vs 
>> PureScript vs GHCjs vs Scalajs 
>>  
>> Functional 
>> UI Platforms, which includes Higher-Order Reflex FRP 
>> .
>>
>>
>> On Friday, March 10, 2017 at 10:21:43 AM UTC-8, Răzvan Cosmin Rădulescu 
>> wrote:
>>>
>>> Well, I have to say, I didn't think the discussion will last this long 
>>> to be honest, I'm pleasantly surprised :). From here on I'm going to handle 
>>> it to you guys as you have more experience than I am have. I hope it gets 
>>> somewhere constructive!
>>>
>>> On Friday, March 10, 2017 at 7:09:36 PM UTC+1, Peter Damoc wrote:

 On Fri, Mar 10, 2017 at 7:51 PM, Mark Hamburg  
 wrote:

> What it feels like one wants to write but can't is the function:
>
> throttle : Float -> Sub msg -> Sub msg
>

 I think you might be able to do this kind of thing in an Effects 
 Manager.  



 -- 
 There is NO FATE, we are the creators.
 blog: http://damoc.ro/

>>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: How do you handle dependencies between updaters?

['Rupert Smith' via Elm Discuss]

On Tuesday, March 21, 2017 at 10:57:43 PM UTC, Mark Hamburg wrote:
>
> We've done that as well in places. But I was mostly looking for an example 
> of how to access extra data during an update. 
>
> On Tue, Mar 21, 2017 at 3:20 PM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> Why not use a secure cookie? Then the browser adds it to the request for 
>> you. It is also more secure and has the advantage that if the user 
>> CTRL+clicks a link in your application opening up the same application in 
>> >1 tab, that the cookies flow across automatically.
>>
>
The reason I pointed this out is that the auth module is one that is likely 
to be needed from a lot of places, so is likely to be at the heart of the 
dependency graph of an application. For that reason, I decided to treat it 
differently.

At first I set up ports so that any module importing Auth could directly 
pass it login/logout/refresh/unauthed requests. Then I changed it to use 
messaging implemented as an effects 
manager: https://github.com/rupertlssmith/elmq.

I only did this for my Auth module, although it could be done for any 
inter-module communication. Really helped to simplify the dependency matrix.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.