[elm-discuss] Re: How to integrate JS library that changes DOM (eg KaTeX)
Nice, this totally works!
Is there a way to not have to specify keys for *every* child? Instead only
specify keys on the children that need it?
Right now I have
view : Model -> Html Msg
view model =
node "div"
[]
[ ( "textarea", textarea [ onInput Change ] [] )
, ( "katex-container", div [ id "katex" ] [] )
, ( ("katex-" ++ (toString (FNV.hashString model))), Html.node
"script" [] [ text ("katex.render('" ++ model ++ "',
document.getElementById('katex'))") ] )
]
Which seems really redundant for the textarea/container, both of which do
not need a key since they're static parts of the page...
The only way that seems doable is to do some kind of wrapping, which is
less than ideal.
Eg, wrap the script in a div, which is a keyed node with one child. This
also seems a little redundant - compromising the code quality?
One other question - how do I run elm-reactor with a custom index.html file
that loads necessary 3rd party resources (like katex.min.js)?
On Thursday, February 16, 2017 at 2:15:43 PM UTC-8, Maxwell Gurewitz wrote:
>
> You're going to want to use
>
> http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Keyed
>
> On Tuesday, February 14, 2017 at 5:41:11 PM UTC-8, vis...@stanford.edu
> wrote:
>>
>> Hi all!
>>
>> Just started using Elm and I'm really liking it.
>>
>> One question I had is whether it is possible to integrate a library like
>> KaTeX that actually modifies the content of a DOM element that is
>> controlled by Elm.
>>
>> If so how would I do that? React/Mithril have ways of interrupting the
>> rendering lifecycle to squeeze in your own behavior, but how does Elm allow
>> for that?
>>
>> Another simple way to do it is to render a script tag, like:
>>
>>
>> KaTeX.render('...', document.getElementById('katex'))
>>
>> I can render a script element, but I need to force elm to re-render the
>> script tag each time, and for that, React allows you to put a key
>> attribute. Is there something similar in Elm?
>>
>> There are a lot of other widget-like js libraries that I wanted to
>> include on my webpage, like musicalabc (abcjs) or mermaid.js, or
>> highlight.js, etc.
>>
>> Any ideas? Thanks!
>>
>> Vishesh
>>
>
--
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: How to integrate JS library that changes DOM (eg KaTeX)
You're going to want to use
http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Keyed
On Tuesday, February 14, 2017 at 5:41:11 PM UTC-8, vis...@stanford.edu
wrote:
>
> Hi all!
>
> Just started using Elm and I'm really liking it.
>
> One question I had is whether it is possible to integrate a library like
> KaTeX that actually modifies the content of a DOM element that is
> controlled by Elm.
>
> If so how would I do that? React/Mithril have ways of interrupting the
> rendering lifecycle to squeeze in your own behavior, but how does Elm allow
> for that?
>
> Another simple way to do it is to render a script tag, like:
>
>
> KaTeX.render('...', document.getElementById('katex'))
>
> I can render a script element, but I need to force elm to re-render the
> script tag each time, and for that, React allows you to put a key
> attribute. Is there something similar in Elm?
>
> There are a lot of other widget-like js libraries that I wanted to include
> on my webpage, like musicalabc (abcjs) or mermaid.js, or highlight.js, etc.
>
> Any ideas? Thanks!
>
> Vishesh
>
--
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: More type checking conundrums
On Thursday, February 16, 2017 at 2:59:41 PM UTC, Rupert Smith wrote: > > On Thursday, February 16, 2017 at 2:50:10 PM UTC, Martin Cerny wrote: >> >> I would say not type checking your example is correct behavior. Since all >> occurrences of a type parameter have to resolve to the same type, the value >> of test is not defined if b resolves to anything other than String. And >> thus the compiler expects you to say it is a string. To be more specific, >> if your code would compile, the following would also compile, which is bad: >> >> intToString: Int -> String >> intToString a = >> "Value:" ++ (toString a) >> >> err: Int->Int >> err = >> test (Specific intToString) >> >> showError:Int >> showError = >> err 5 --Now I am casting a string "Value:5" to int. >> >> > > I think you got the type of the 'err' function wrong? It would be Int -> > String (as it applies test to a Val Int String). So err 5 would be > "Value:5", a String as expected. > Sorry, my bad, but its easy to get confused. You are right, "Specific intToString" has type "Val Int b", you then bound b to Int in the type spec for err, so it does have the type "Int -> Int". So the problem is that using the MGU would allow under-specified return types which can then be coerced into the wrong type leading to a runtime error. -- 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: More type checking conundrums
I would say not type checking your example is correct behavior. Since all occurrences of a type parameter have to resolve to the same type, the value of test is not defined if b resolves to anything other than String. And thus the compiler expects you to say it is a string. To be more specific, if your code would compile, the following would also compile, which is bad: intToString: Int -> String intToString a = "Value:" ++ (toString a) err: Int->Int err = test (Specific intToString) showError:Int showError = err 5 --Now I am casting a string "Value:5" to int. Martin On Thursday, 16 February 2017 12:31:25 UTC+1, Rupert Smith wrote: > > Related to what I looked into with extensible records, I was also curious > as to how strict the typing of case statements is. So I tried this: > > type Val a b > = General (a -> b) > | Specific (a -> String) > > > test : Val a b -> (a -> b) > test val = > case val of > General func -> > func > > Specific func -> > func > > Should this not type check? test is returning a function which will accept > any type and will prouce some other type that we know nothing about. "a -> > String" is a more specific instance of such a function, so should type > check as "a -> b"? > > Is the case statement typing too strict in requiring an exact match of all > its branches? Could it not work by calculating the most general unifier of > its branches and assume that type? MGU of a->b and a->String is a->b as it > is the minimal thing that unifies with both. > -- 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] Is type inference in Elm fully decideable?
On Wednesday, February 15, 2017 at 8:49:13 PM UTC, Rupert Smith wrote:
>
> What I don't understand is why this fails to type check:
>
> mapWhenWithPosition : (WithPosition b -> a) -> State -> Maybe a
> mapWhenWithPosition func state =
> case state of
> Aware rect ->
> Just <| func rect
>
> Active rect ->
> Just <| func rect
>
> Inactive rect ->
> Just <| func rect
>
> _ ->
> Nothing
>
I can get it to type check by defining the more general function in a
let..in construct:
mapWhenWithPosition : (WithPosition {} -> a) -> State -> Maybe a
mapWhenWithPosition func state =
let
func_ : WithPosition b -> a
func_ { rect } =
func { rect = rect }
in
case state of
Aware position ->
Just <| func_ position
Active position ->
Just <| func_ position
Inactive position ->
Just <| func_ position
_ ->
Nothing
let..in behaves somewhat like the existential qualifier - "let us say that
a more general type exists, by defining its implementation". I still have
to unpack and repack the record but at least now, only once.
--
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] Is type inference in Elm fully decideable?
On Wednesday, February 15, 2017 at 10:19:34 PM UTC, Max Goldstein wrote:
>
> I think this code would be simpler, and no less expressive, if the
> function argument was Rectangle -> a. The fact that it's wrapped with some
> arbitrary fields is mixing concerns.
>
Yes, I did in fact start out with Rectangle -> a. The reason I generalized
it a bit more, even though I only have the 'rect' field, is because I am
going to add some more fields to the WithPosition type. I also need a
yOffset : Float field, since some of my UI elements are positioned absolute
wrt to the page body, and some are positioned fixed. elm-dom gives me the
absolute position wrt to the body, so I also need to factor in the body
scroll offset to position the fixed UI elements.
> I anyone using extensible records much?
>
>
> I don't think people are using extensible record type aliases much. The {
> a | fieldICareAbout : Int } -> Thing pattern is useful, though. (For
> example, to call a view helper with the whole model but guarantee that it
> can't look at certain fields.)
>
Similarly, you could argue that { a | fieldICareAbout : Int } -> Thing is
no less expressive than Int -> Thing. It gets more usefull when you have >1
field.
Nesting these field definitions makes the code a lot less readable then
> just listing the records exactly. Try to make your type definitions more
> explicit, and use your functions signatures to abstract away some of the
> details.
>
> State.mapPosition : (Rectangle -> a) -> State -> Maybe a
> State.updatePosition : (Rectangle -> Rectangle) -> State -> State
>
Thanks for your thoughts, and yes this is more readable I agree. I was
really just trying to explore all the options and find out what extensible
records might help me with. They are quite difficult to understand and its
easy to be lulled into thinking they provide sub-typing when they do not.
I'll see if I can contribute something to the FAQ or community docs to
explain their limitations to the unwary.
--
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] More type checking conundrums
Related to what I looked into with extensible records, I was also curious as to how strict the typing of case statements is. So I tried this: type Val a b = General (a -> b) | Specific (a -> String) test : Val a b -> (a -> b) test val = case val of General func -> func Specific func -> func Should this not type check? test is returning a function which will accept any type and will prouce some other type that we know nothing about. "a -> String" is a more specific instance of such a function, so should type check as "a -> b"? Is the case statement typing too strict in requiring an exact match of all its branches? Could it not work by calculating the most general unifier of its branches and assume that type? MGU of a->b and a->String is a->b as it is the minimal thing that unifies with both. -- 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.
