Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

[Janis Voigtländer]

Mark, wow, a lot of material. I’m not able to digest all of it right now.
But something quick I want to say, because I have the impression that there
is a misunderstanding about the current state of tick batching support.

This:

Since I wasn’t proposing to get rid of subscriptions and since this
functionality is covered through subscriptions, my proposal arguably
doesn’t cause a problem.

baffles me. I’m not sure what you mean by “this functionality is covered
through subscriptions”. Tick batching wasn’t covered through signals (the
closest predecessors of subscriptions), and isn’t covered through
subscriptions (or at all!) right now.

Specifically and relatedly, concerning this:

The special behavior for tick wasn’t particularly documented for the 0.16
Effects module and isn’t really documented for the 0.17+ AnimationFrame
module.

I should clarify that the tick batching trick as existed in the 0.16 Effects
module is *not implemented* for Elm 0.17+. Apparently since gamey stuff is
not anymore in Elm’s focus, Evan didn’t bring the “first ever effect
manager” over to the new world when effect managers as such became a thing.

(Did I indicate previously that tick batching as existed before is a thing
currently in core or other 0.17/0.18 packages? I don’t think so. I was only
bringing it up as a thing that can be done with effect managers and
benefits from, maybe even is absolutely dependent on, having separate
concepts of Task and Cmd. To decide about maintaining that latter stance,
will require digesting your material more fully.)
​

2016-12-11 21:26 GMT+01:00 Mark Hamburg :

> Since I wasn't proposing to get rid of subscriptions and since this
> functionality is covered through subscriptions, my proposal arguably
> doesn't cause a problem. But that's just getting through the loophole of
> this specific example to dodge this particular case, so let me see if I can
> get straight what the special property is that we need to preserve if we
> were still trying to implement a tick command in the same manner of the
> 0.16 tick effect. (It's worth noting as a side note that in 0.16, all
> effects other than tick were tasks, so obviously tasks are close to
> covering the role of commands — née effects — but tick may point to extra
> wrinkles.) I'm not going to assume a constraint by the current task
> implementation, but any revised implementation has to have a clear behavior
> in conjunction with the existing task APIs since its those APIs that make
> tasks an attractive alternative to commands.
>
> The special behavior for tick wasn't particularly documented for the 0.16
> Effects module and isn't really documented for the 0.17+ AnimationFrame
> module. Am I correct that the concern is that when the animation frame
> "arrives":
>
>
>1. We run all of the update functions before actually calling the view
>function; and
>2. Any tick effects that result from those updates will be batched
>together for the next animation frame
>
> Was there anything else that I'm missing?
>
> The first point means that any implementation is going to have to be built
> in conjunction with the Elm runtime since coordinating with the call of the
> view function requires knowledge of when and how the view function gets
> run. But since the whole point of this is to coordinate with the view
> function that shouldn't be surprising nor is it particularly odd. It does
> mean that my simple example using port tasks wouldn't work because it
> wouldn't enjoy that coordination, but extra requirements add extra
> implementation details.
>
> So, what we want is that we can divide time up with a series of animation
> frame events and at each animation frame event, we want to start a new
> epoch for collecting tick effects, run the updates driven by all effects
> collected for the previous epoch, and then do the view rendering. A naive
> implementation will just keep listening for all animation frames. A more
> sophisticated implementation will take steps to shutdown that observation
> when it is no longer necessary.
>
> The vague handwaving in the above is seemingly around what it means to say
> "run the updates driven by all effects collected for the previous epoch".
> In particular, how does this interact with task chains built using andThen,
> etc.? I am going to make a distinction between two ways to specify
> successor computation on a task. In one case with map the results or the
> error coming from the task to produce a new result or error. In the other,
> we map the results or the error coming from the task to produce a new task.
> I would argue that the first category is what leads to actual messages for
> the model. The second can be viewed as making no changes to the model but
> queueing new task executions.
>
> So, how could this work in a task-based scenario? I'm going to speak of
> tasks initiating and resolving to distinguish between when they have code
> invoked v when they deliver values.
>

[elm-discuss] Re: Using flat-file JSON fixtures in elm-test and API tests

[Richard Feldman]

Thanks for the level of detail on this! Testing that things are wired up as 
expected is something I'd like to add to elm-test.

I hadn't thought about the "shared fixtures" angle. It's definitely 
interesting!

I'm also curious to see if anyone else has any similar use cases, and their 
similarities/differences to this one.

-- 
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: Using flat-file JSON fixtures in elm-test and API tests

[Oliver Searle-Barnes]

This is a slightly different approach to the problem but thought you might 
be interested to see it, https://github.com/realestate-com-au/pact.

On Monday, 12 December 2016 00:16:21 UTC+1, Jan Fornoff wrote:
>
> Hi everyone!
>
> I'd like to propose an idea that I've been playing with for a bit.
>
> *Core problem:*
>
> Testing an API is not too challenging, and the tests are pretty fast too 
> (e.g., controller and unit tests in Ruby on Rails).
> Verifying that an Elm frontend works is fairly straightforward as well and 
> fast (with elm-test).
>
> To ensure that the interactions between Elm and the API work as intended, 
> one approach is to utilize an End-To-End testing approach (such as 
> simulating user interaction through PhantomJS, Selenium or similar).
> However, those tests are slow and therefore a tradeoff between test suite 
> runtime and amount of test cases needs to be made.
>
> *Possible solution:*
>
> Given the constraints above, it is a prudent approach to focus End-To-End 
> tests to the more mission-critical features of an application.
> In my experience, such tests mostly verify that everything is plugged 
> together correctly and works "at first sight" (i.e., not exploring every 
> last bit of functionality).
>
> Compatibility between the frontend application and the API endpoints being 
> used is a point where bugs can easily sneak in and increase the desire for 
> E2E tests.
>
> To deal with this, a possible solution might include sharing fixtures 
> between API and frontend tests, such that:
> - API tests verify that responses conform with a JSON fixture file
> - Frontend test use the same JSON fixture files as "stubbed" API responses
>
> I've created a small infographic illustrating the idea with an example right 
> here .
>
>
> Please let me hear your thoughts on this! :-)
> Best regards,
> Jan
>

-- 
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] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[W. Brian Gourlie]

With regards to working with binary files, what all does that entail?  I 
assume support for typed-arrays and ArrayBuffer... anything else?

On Sunday, December 11, 2016 at 3:59:08 PM UTC-6, Zinggi wrote:
>
> (Elm discuss is fine for this. There are almost no open discussions on elm 
> dev, as these are usually a waste of everyone's time.)
>
> For me, these things would be nice to have:
>   * WebAudio API
>   * File upload
>   * Working with binary files, e.g. parsing
>   * Persistent cache, offering access to local storage and maybe also 
> IndexedDB
>   (It's already there, but not released yet: 
> https://github.com/elm-lang/persistent-cache)
>   * Gamepad API
>
>
> On Sunday, 11 December 2016 21:17:50 UTC+1, W. Brian Gourlie wrote:
>>
>> Per the elm-dev mailing list guidelines, I don't think this would be 
>> appropriate there.  I'm also mostly interested in what other users feel are 
>> shortcomings. Perhaps if I had a curated list of things, I could try and 
>> bring it to the devs attention.  
>>
>> On Sunday, December 11, 2016 at 10:09:55 AM UTC-6, Duane Johnson wrote:
>>>
>>> I think this list is for discussion and is not as frequented by the elm 
>>> core developers, so you might try 
>>> https://groups.google.com/forum/?fromgroups#!forum/elm-dev
>>>
>>> They still show up here on occasion, but my impression is that they 
>>> primarily hang out over there.
>>>
>>> On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie  
>>> wrote:
>>>
 I've noticed a fair amount of discussion around various shortcomings of 
 Elm's native libraries. Particular examples that affect me are the limited 
 Websocket API and no native typed-array implementation.  The former is 
 limits me quite a bit, while the latter is simply a nice-to-have. I've 
 seen 
 clamoring for file upload support as well. In any event, it would be 
 interesting to get an idea of what people feel are the Elm's biggest 
 shortcomings in terms of natively supported features.

 One thing that is frustrating as an Elm user is feeling in the dark 
 when it comes to feature requests. I know the team likes to batch their 
 efforts, but it's disheartening to see something sit for months 
 unanswered. 
 I'm hoping for two things to come out of this post: Get an idea of what 
 the 
 biggest pain points are in terms of natively supported API's, and to get 
 an 
 idea of what the Elm devs think. Any feedback really would be nice!

 Brian

 -- 
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>

-- 
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] Using flat-file JSON fixtures in elm-test and API tests

[Jan Fornoff]

Hi everyone!

I'd like to propose an idea that I've been playing with for a bit.

*Core problem:*

Testing an API is not too challenging, and the tests are pretty fast too 
(e.g., controller and unit tests in Ruby on Rails).
Verifying that an Elm frontend works is fairly straightforward as well and 
fast (with elm-test).

To ensure that the interactions between Elm and the API work as intended, 
one approach is to utilize an End-To-End testing approach (such as 
simulating user interaction through PhantomJS, Selenium or similar).
However, those tests are slow and therefore a tradeoff between test suite 
runtime and amount of test cases needs to be made.

*Possible solution:*

Given the constraints above, it is a prudent approach to focus End-To-End 
tests to the more mission-critical features of an application.
In my experience, such tests mostly verify that everything is plugged 
together correctly and works "at first sight" (i.e., not exploring every 
last bit of functionality).

Compatibility between the frontend application and the API endpoints being 
used is a point where bugs can easily sneak in and increase the desire for 
E2E tests.

To deal with this, a possible solution might include sharing fixtures 
between API and frontend tests, such that:
- API tests verify that responses conform with a JSON fixture file
- Frontend test use the same JSON fixture files as "stubbed" API responses

I've created a small infographic illustrating the idea with an example right 
here .


Please let me hear your thoughts on this! :-)
Best regards,
Jan

-- 
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] elm-lang/Navigation with hash and query string

[Nick H]

Maybe Bogdanp/elm-querystring  could be helpful?

On Sun, Dec 11, 2016 at 2:23 PM, Charlie Koster  wrote:

> I don't disagree with anything your wrote there, but I still have this
> problem to deal with now. The path of least resistance happens to also be
> the path that uses query strings that are technically correct (nevermind
> about technically correct URLs).
>
> If a library comes along and makes parsing hashes that contain semantic
> query strings easy, then I'll consider using that library. At the moment
> the solution I have now contains a very small workaround and has unblocked
> me from being able to use query string parameters.
>
> --
> 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.
>

-- 
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] elm-lang/Navigation with hash and query string

[Charlie Koster]

I don't disagree with anything your wrote there, but I still have this 
problem to deal with now. The path of least resistance happens to also be 
the path that uses query strings that are technically correct (nevermind 
about technically correct URLs).

If a library comes along and makes parsing hashes that contain semantic 
query strings easy, then I'll consider using that library. At the moment 
the solution I have now contains a very small workaround and has unblocked 
me from being able to use query string parameters.

-- 
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: Maximum call stack size exceeded while parsing generated code

[Paul D]

I hit the same problem after updating my project from 0.17 to 0.18. Breaks 
in Chromium (with or without debug mode), works in Firefox.

My list has 650 items. I wouldn't expect to be hitting any upper limits 
with a list of that size. Breaking it up into smaller lists seems like more 
of a workaround than a long term solution. Does anyone know what the 
underlying issue is and why it seems to be more prevalent in 0.18?


On Monday, December 5, 2016 at 1:57:08 PM UTC-6, Nick H wrote:
>
> Glad you found a solution!
>
> On Sun, Dec 4, 2016 at 8:43 PM, Iain Gray  > wrote:
>
>> It turned out to be an instance of this 
>> . I have a list of 
>> time-zones that I use for a drop-down list, which was big enough to cause 
>> the stack overflow. As the issue-poster mentioned, I was able to fix it by 
>> splitting my list into multiple pieces and List.concat'ing them together.
>>
>> Thanks for the suggestions everyone!
>>
>>
>> On Saturday, December 3, 2016 at 7:40:41 PM UTC-6, Iain Gray wrote:
>>>
>>> I'm having a strange problem and was wondering if anyone had any 
>>> suggestions on how to pinpoint what is causing it.
>>>
>>> I have an Elm app that compiles in 0.18, but the generated javascript 
>>> code is throwing a "RangeError: Maximum call stack size exceeded" as soon 
>>> as the javascript file is loaded into Chrome. I do not have this problem in 
>>> Firefox, but I can reproduce it in nodejs/esprima as follows:
>>>
>>> var esprima = require('esprima');
>>> var fs = require('fs');
>>> var filePath = path.join('.', 'elm.js');
>>>
>>> fs.readFile(filePath, 'utf8', function(err, data) {
>>>   console.log(esprima.parse(data));
>>> });
>>>
>>> RangeError: Maximum call stack size exceeded
>>> at isKeyword (.../node_modules/esprima/esprima.js:359:23)
>>> at scanIdentifier (.../node_modules/esprima/esprima.js:729:20)
>>> at advance (.../node_modules/esprima/esprima.js:1573:21)
>>> at lex (.../node_modules/esprima/esprima.js:1691:78)
>>> at expect (.../node_modules/esprima/esprima.js:2521:21)
>>> at parseObjectInitializer (.../node_modules/esprima/esprima.js:3047:
>>> 9)
>>> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
>>> at parsePrimaryExpression (.../node_modules/esprima/esprima.js:3247:
>>> 20)
>>> at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
>>> at parseLeftHandSideExpressionAllowCall (.../node_modules/esprima/
>>> esprima.js:3414:20)
>>>
>>> If I start node with --stack-size=1200, I no longer get the error and 
>>> esprima can successfully parse the code. Unfortunately, I can't seem to do 
>>> this with Chrome. I tried:
>>>
>>>   
>>> Error.stackTraceLimit = 1200;
>>> var js = document.createElement("script");
>>> js.type = "text/javascript";
>>> js.src = './elm.js';
>>> document.body.appendChild(js);
>>>   
>>>
>>> ... which doesn't seem to change anything.
>>>
>>> I've been commenting out different sections of my code in an attempt to 
>>> see what part is ultimately causing this, but that has been pretty painful. 
>>> If anyone has any suggestions, I'd love some advice.
>>>
>>> Thanks,
>>> Iain
>>>
>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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] elm-lang/Navigation with hash and query string

[Witold Szczerba]

There is nothing "technically" incorrect in e.g.
15

All the SPA I have seen had URLs like this, because this is just the
browser who cares about that part of the location.

This is why, when creating e.g.:
next
there is no need to hack browser to stop it from page reload as this is all
about going somewhere else on the same "Page", the "P" in SPA.

All I wrote in Elm was a small app with two forms and I did not have to
parse location, but in AngularJS the location services (or similar plugins)
have no troubles parsing and destructuring the page fragment part.

Looking at https://github.com/evancz/url-parser it seems that this library
is covering only very basic parsing capabilities, there should be more
complete libs in the public package repository though.

Regards,
Witold Szczerba

On Sun, Dec 11, 2016 at 10:35 PM, Charlie Koster 
wrote:

> If I use hashes I now have to do manual work in order to use and parse
> query strings.
>
> Let's say I want to handle a query string such as
> "myPage?search=things=asc". If there's a hash in front of "myPage"
> the query string doesn't get interpreted as a search string by
> elm-lang/Navigation (correct behavior), and evancz/url-parser doesn't parse
> my query string parameters. As a result, I'd have to parse the technically
> incorrect query string from the hash by hand.
>
> I'd rather use a URL where the query string is technically correct in
> order to avoid future issues with these packages or other url and routing
> packages.
>
> --
> 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.
>

-- 
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] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Zinggi]

(Elm discuss is fine for this. There are almost no open discussions on elm 
dev, as these are usually a waste of everyone's time.)

For me, these things would be nice to have:
  * WebAudio API
  * File upload
  * Working with binary files, e.g. parsing
  * Persistent cache, offering access to local storage and maybe also 
IndexedDB
  (It's already there, but not released yet: 
https://github.com/elm-lang/persistent-cache)
  * Gamepad API


On Sunday, 11 December 2016 21:17:50 UTC+1, W. Brian Gourlie wrote:
>
> Per the elm-dev mailing list guidelines, I don't think this would be 
> appropriate there.  I'm also mostly interested in what other users feel are 
> shortcomings. Perhaps if I had a curated list of things, I could try and 
> bring it to the devs attention.  
>
> On Sunday, December 11, 2016 at 10:09:55 AM UTC-6, Duane Johnson wrote:
>>
>> I think this list is for discussion and is not as frequented by the elm 
>> core developers, so you might try 
>> https://groups.google.com/forum/?fromgroups#!forum/elm-dev
>>
>> They still show up here on occasion, but my impression is that they 
>> primarily hang out over there.
>>
>> On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie  
>> wrote:
>>
>>> I've noticed a fair amount of discussion around various shortcomings of 
>>> Elm's native libraries. Particular examples that affect me are the limited 
>>> Websocket API and no native typed-array implementation.  The former is 
>>> limits me quite a bit, while the latter is simply a nice-to-have. I've seen 
>>> clamoring for file upload support as well. In any event, it would be 
>>> interesting to get an idea of what people feel are the Elm's biggest 
>>> shortcomings in terms of natively supported features.
>>>
>>> One thing that is frustrating as an Elm user is feeling in the dark when 
>>> it comes to feature requests. I know the team likes to batch their efforts, 
>>> but it's disheartening to see something sit for months unanswered. I'm 
>>> hoping for two things to come out of this post: Get an idea of what the 
>>> biggest pain points are in terms of natively supported API's, and to get an 
>>> idea of what the Elm devs think. Any feedback really would be nice!
>>>
>>> Brian
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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] elm-lang/Navigation with hash and query string

[Charlie Koster]

If I use hashes I now have to do manual work in order to use and parse 
query strings.

Let's say I want to handle a query string such as 
"myPage?search=things=asc". If there's a hash in front of "myPage" 
the query string doesn't get interpreted as a search string by 
elm-lang/Navigation (correct behavior), and evancz/url-parser doesn't parse 
my query string parameters. As a result, I'd have to parse the technically 
incorrect query string from the hash by hand.

I'd rather use a URL where the query string is technically correct in order 
to avoid future issues with these packages or other url and routing 
packages.

-- 
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] elm-lang/Navigation with hash and query string

[Witold Szczerba]

Why is it so important that your links does not start with a `#` aka
fragment part?

Regards,
Witold Szczerba

On Sun, Dec 11, 2016 at 4:51 PM, Charlie Koster  wrote:

> I think I came up with a workable solution by adding a tiny bit of
> abstraction.
>
> import Html exposing (Attribute, Html, a)
> import Html.Events exposing (onWithOptions, defaultOptions)
> import Model exposing (Msg(..))
> import Json.Decode as Json
>
>
> link : String -> List (Attribute Msg) -> List (Html Msg) -> Html Msg
> link route attributes children =
> let
> clickHandler =
> onWithOptions "click" defaultOptions <| Json.succeed <|
> NavigateTo route
>
> attrs =
> clickHandler :: attributes
> in
> a
> attrs
> children
>
> What this allows me to do is replace these:
>
> a [ onClick (NavMsg1 param1), class "some class", title "Do something" ] [
> text "Do something" ]
> a [ onClick (NavMsg2), title "Do something else" ] [ text "Dom something
> else" ]
> a [ onClick (NavMsg3 param2 param3), class "is-disabled", title "Delete
> thing" ] [ text "Delete thing" ]
>
> ..which has a lot of custom Msgs (one Msg per route).. and replace it with
>
> link ("/something?param1=" ++ param1) [ class "some class", title "Do
> something" ] [ text "Do something" ]
> link ("/home") [ title "Do something else" ] [ text "Dom something else" ]
> link ("/deletePage?param2=" ++ param2 ++ "=" ++ param3) [ class
> "is-disabled", title "Delete thing" ] [ text "Delete thing" ]
>
> The above reads very similar to using an anchor tag with an href attribute
> which is what I was hoping for.
>
> Additionally, just as with your solution, there is only one Msg for going
> to the different pages rather than a unique Msg for every different page.
>
> --
> 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.
>

-- 
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: [elm-dev] Re: 0.17 Tasks vs Cmds

[Mark Hamburg]

I get uncomfortable when I wave my hands too much, so here is a more
concrete version of the task logic as sketched out in Lua. You can skip
this unless you too were bothered by my handwaving in the previous message.

Essentially, tasks are objects that can be invoked and we use different
kinds of invocations for different kinds of tasks. I've simplified to
assume only results rather than errors or results. There are two queues of
functions to execute. The immediate queue is used purely to deal with the
general rule that it's bad to invoke a callback immediately within
imperative code. So, instead we push the response onto a queue that is
drained essentially as part of any processing that starts work. The
deferred queue is for andThen computations where we are producing a series
of tasks representing extra work to do. This queue gets drained as time and
other events in the system allow.

function Succeed:invoke( fn )
enqueueImmediate( function() fn( self._value ) end )
end

function Map:invoke( fn )
self._input:invoke( function( result ) fn( self._fn( result ) ) )
end

function AndThen:invoke( fn )
self._input:invoke( function( result )
enqueueDeferred( function() self._fn( result ):invoke( fn ) )
end )
end


An update cycle produces some tasks. For each of those tasks, we call
task:invoke(
updateWithMessage ) where updateWithMessage will run one round of the
update cycle:

function updateWithMessage( message )
local updateResult =
update( message, model )
model = updateResult.model
for i = 1, #updateResult.tasks do
updateResult.tasks[ i ]:invoke( updateWithMessage )
end
drainImmediateQueue() -- will return immediately if already draining
end



So, in the context of the tick logic, the tick task would add functions to
the tick pool:

function Tick:invoke( fn )
tickPool[ #tickPool + 1 ] = fn
requestAnimationFrameIfNecessary()
end

The animation frame event then does the following:

function processTicks( time )
local oldTickPool = tickPool
tickPool = { }
for i = 1, #oldTickPool do
local fn = oldTickPool[ i ]
enqueueImmediate( function() fn( time ) end )
end
drainImmediateQueue() -- run the immediate queue until empty
end


This results in all of the outstanding tick event invocation callbacks
getting queued for execution with the current time. Ones that are on an
andThen free path back to the updateWithMessage will result in those
updates getting run. Those on paths involving andThen will result in work
being put on the deferred queue.

Looking at this implementation sketch, it even becomes clear that the
deferred queue is non-essential. It exists to reduce the amount of work we
do while processing an animation frame or between processing external
messages. What it points to in general is that when processing ticks, we
want to control when the updates they produce get run and not let them get
stuck behind everything else in the message queue — though even that is
maybe not a bad thing, we could argue that we should process all incoming
updates before rendering an animation frame.

Mark

On Sun, Dec 11, 2016 at 12:26 PM, Mark Hamburg 
wrote:

> Since I wasn't proposing to get rid of subscriptions and since this
> functionality is covered through subscriptions, my proposal arguably
> doesn't cause a problem. But that's just getting through the loophole of
> this specific example to dodge this particular case, so let me see if I can
> get straight what the special property is that we need to preserve if we
> were still trying to implement a tick command in the same manner of the
> 0.16 tick effect. (It's worth noting as a side note that in 0.16, all
> effects other than tick were tasks, so obviously tasks are close to
> covering the role of commands — née effects — but tick may point to extra
> wrinkles.) I'm not going to assume a constraint by the current task
> implementation, but any revised implementation has to have a clear behavior
> in conjunction with the existing task APIs since its those APIs that make
> tasks an attractive alternative to commands.
>
> The special behavior for tick wasn't particularly documented for the 0.16
> Effects module and isn't really documented for the 0.17+ AnimationFrame
> module. Am I correct that the concern is that when the animation frame
> "arrives":
>
>
>1. We run all of the update functions before actually calling the view
>function; and
>2. Any tick effects that result from those updates will be batched
>together for the next animation frame
>
> Was there anything else that I'm missing?
>
> The first point means that any implementation is going to have to be built
> in conjunction with the Elm runtime since coordinating with the call of the
> view function requires knowledge of when and how the view function gets
> run. But since the whole point of this is to coordinate with the view
> function that shouldn't be surprising nor is it particularly odd. It does
> mean that my simple example using port tasks wouldn't work because 

Re: [elm-discuss] Re: Documentation storage : IN or OUT ?

[Nick H]

Yes, I'm curious what exactly your concerns are with the current
documentation system. Seems like removing all documentation from the source
code would just make it harder to notice mistakes.

On Sun, Dec 11, 2016 at 9:52 AM, Max Goldstein 
wrote:

> You're going to be more specific about what concerns you about the current
> format. The Elm community likes to work together towards solutions, not get
> into debates. To that end, the tooling and conventions create a
> multi-layered system of documentation:
>
> As in any language, *code comments* are used to document *individual
> lines of code* whose meaning is not obvious.
>
> *Declaration comments* with the {-| prefix are used to document *public
> values and types*. (A "value" is a function or a definition.) These work
> in concert with the type annotation. Because the comment and annotation are
> displayed together in the rendered docs, they are written together in code.
>
> The *module comment* at the top of the *file/module* gives information
> about the module: why it exists as a logical grouping of code. This comment
> also includes @docs declarations to define the order that public functions
> are documented. They are usually separated by headers (it's just markdown)
> and each section may also include a comment. Elm encourages library authors
> to use these features so that their module docs are sensible when read top
> to bottom. There is also a way to preview docs
>  prior to publication.
>
> The *README* for each *package* includes information about what the
> package does, how to start using it, and what to look for in the more
> detailed module docs. They may also include instructions for filing bugs or
> upgrading from previous versions of the package or language.
>
> Finally *guides and blog posts* will go into depth and examples on how to
> accomplish a* useful unit of work*, such as JSON decoding or refactoring
> a union type. These may focus on a module from the core library, one or
> more third-party libraries working together, or a language feature.
>
> You will notice that READMEs and guides are not source code files, but are
> valuable parts of the hierarchical documentation system.
>
> --
> 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.
>

-- 
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: [elm-dev] Re: 0.17 Tasks vs Cmds

[Mark Hamburg]

Since I wasn't proposing to get rid of subscriptions and since this
functionality is covered through subscriptions, my proposal arguably
doesn't cause a problem. But that's just getting through the loophole of
this specific example to dodge this particular case, so let me see if I can
get straight what the special property is that we need to preserve if we
were still trying to implement a tick command in the same manner of the
0.16 tick effect. (It's worth noting as a side note that in 0.16, all
effects other than tick were tasks, so obviously tasks are close to
covering the role of commands — née effects — but tick may point to extra
wrinkles.) I'm not going to assume a constraint by the current task
implementation, but any revised implementation has to have a clear behavior
in conjunction with the existing task APIs since its those APIs that make
tasks an attractive alternative to commands.

The special behavior for tick wasn't particularly documented for the 0.16
Effects module and isn't really documented for the 0.17+ AnimationFrame
module. Am I correct that the concern is that when the animation frame
"arrives":


   1. We run all of the update functions before actually calling the view
   function; and
   2. Any tick effects that result from those updates will be batched
   together for the next animation frame

Was there anything else that I'm missing?

The first point means that any implementation is going to have to be built
in conjunction with the Elm runtime since coordinating with the call of the
view function requires knowledge of when and how the view function gets
run. But since the whole point of this is to coordinate with the view
function that shouldn't be surprising nor is it particularly odd. It does
mean that my simple example using port tasks wouldn't work because it
wouldn't enjoy that coordination, but extra requirements add extra
implementation details.

So, what we want is that we can divide time up with a series of animation
frame events and at each animation frame event, we want to start a new
epoch for collecting tick effects, run the updates driven by all effects
collected for the previous epoch, and then do the view rendering. A naive
implementation will just keep listening for all animation frames. A more
sophisticated implementation will take steps to shutdown that observation
when it is no longer necessary.

The vague handwaving in the above is seemingly around what it means to say
"run the updates driven by all effects collected for the previous epoch".
In particular, how does this interact with task chains built using andThen,
etc.? I am going to make a distinction between two ways to specify
successor computation on a task. In one case with map the results or the
error coming from the task to produce a new result or error. In the other,
we map the results or the error coming from the task to produce a new task.
I would argue that the first category is what leads to actual messages for
the model. The second can be viewed as making no changes to the model but
queueing new task executions.

So, how could this work in a task-based scenario? I'm going to speak of
tasks initiating and resolving to distinguish between when they have code
invoked v when they deliver values.

When a tick task initiates, it adds itself to the set of tick task
executions for the current tick epoch.

When we receive an animation frame call, we do the following:

   1. We grab the contents of the tick epoch set and reset the set to empty
   2. For each of the tick executions in the tick epoch set grabbed in (1),
   we resolve the execution using the current time. This means running down
   the network of tasks chained onto the executions. For cases where we map
   the result or error to a new result or error, we do so and keep working
   down the chain. For cases where we map the result or error to a new task,
   we queue that task for execution.
   3. We execute the view function.

In this way, we deliver all of the updates that are simply dependent on the
tick event or a mapping thereof while initiating any further computations
that were waiting for the tick event.

The other piece of concern is how task queueing works and when tasks get to
execute. I would probably go for a structure on the task queue in which it
is also divided into epochs. We process all of the tasks within an epoch.
Any tasks produced during this processing as a result of andThen, etc. go
in the next epoch. All tasks produced during an update go in the current
epoch which we process at the end of the update. This design keeps chains
of tasks from blocking other update processing. We could go further and
pull tasks generated by tasks off of a queue that executes even more
incrementally. The key point is that all of the tasks from an update get
initiated immediately following the update and tasks initiated from other
tasks happen as we have time to process them.

In the case of ticks, this means that a tick task that initiates 

Re: [elm-discuss] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[W. Brian Gourlie]

Per the elm-dev mailing list guidelines, I don't think this would be 
appropriate there.  I'm also mostly interested in what other users feel are 
shortcomings. Perhaps if I had a curated list of things, I could try and 
bring it to the devs attention.  

On Sunday, December 11, 2016 at 10:09:55 AM UTC-6, Duane Johnson wrote:
>
> I think this list is for discussion and is not as frequented by the elm 
> core developers, so you might try 
> https://groups.google.com/forum/?fromgroups#!forum/elm-dev
>
> They still show up here on occasion, but my impression is that they 
> primarily hang out over there.
>
> On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie  > wrote:
>
>> I've noticed a fair amount of discussion around various shortcomings of 
>> Elm's native libraries. Particular examples that affect me are the limited 
>> Websocket API and no native typed-array implementation.  The former is 
>> limits me quite a bit, while the latter is simply a nice-to-have. I've seen 
>> clamoring for file upload support as well. In any event, it would be 
>> interesting to get an idea of what people feel are the Elm's biggest 
>> shortcomings in terms of natively supported features.
>>
>> One thing that is frustrating as an Elm user is feeling in the dark when 
>> it comes to feature requests. I know the team likes to batch their efforts, 
>> but it's disheartening to see something sit for months unanswered. I'm 
>> hoping for two things to come out of this post: Get an idea of what the 
>> biggest pain points are in terms of natively supported API's, and to get an 
>> idea of what the Elm devs think. Any feedback really would be nice!
>>
>> Brian
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 use Dict.empty?

[Max Goldstein]

If you can isolate an sscce  of the bad error message, 
you can report it to the catalog 
.

-- 
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 use Dict.empty?

[Bob Lee]

Thanks for the quick replies.   I found my mistake (my Dict declaration 
what missing a type).   Coming from Haskell, I find Elm's error messages a 
Joy as they are normally right on the money.  This was a rare instance 
where the error message had me barking up the wrong tree.   

Having said that, even one line examples in the  package Docs is extremely 
helpful but not always there.  Such an example would have ruled out "maybe 
I am using empy incorrectly" 

Thanks again 



On Sunday, December 11, 2016 at 12:07:39 PM UTC-5, Bob Lee wrote:
>
> (Or more generally, how to make an empty Dict)
>
> I have guessed the following:
>
> r=SomeRecordType f1 f2 Dict.empty
>
> the compiler error I get back is a type mismatch (expected 
> SomeOtherRecordType 
> but actual was Dict k v)
>
> I also tried to be sneaky and use Dict.fromList [] but got the same error
>
> Does someone have an example?
>

-- 
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] How to use Dict.empty?

[Wouter In t Velt]

The error message from the compiler says that the third thing in your 
SomeRecordType should be a SomeOtherRecordType.

But you are passing it an empty Dict.

Which suggests that you have defined "SomeOtherRecordType" as something other 
than a Dict

-- 
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: Documentation storage : IN or OUT ?

[Max Goldstein]

You're going to be more specific about what concerns you about the current 
format. The Elm community likes to work together towards solutions, not get 
into debates. To that end, the tooling and conventions create a 
multi-layered system of documentation:

As in any language, *code comments* are used to document *individual lines 
of code* whose meaning is not obvious.

*Declaration comments* with the {-| prefix are used to document *public 
values and types*. (A "value" is a function or a definition.) These work in 
concert with the type annotation. Because the comment and annotation are 
displayed together in the rendered docs, they are written together in code.

The *module comment* at the top of the *file/module* gives information 
about the module: why it exists as a logical grouping of code. This comment 
also includes @docs declarations to define the order that public functions 
are documented. They are usually separated by headers (it's just markdown) 
and each section may also include a comment. Elm encourages library authors 
to use these features so that their module docs are sensible when read top 
to bottom. There is also a way to preview docs 
 prior to publication.

The *README* for each *package* includes information about what the package 
does, how to start using it, and what to look for in the more detailed 
module docs. They may also include instructions for filing bugs or 
upgrading from previous versions of the package or language.

Finally *guides and blog posts* will go into depth and examples on how to 
accomplish a* useful unit of work*, such as JSON decoding or refactoring a 
union type. These may focus on a module from the core library, one or more 
third-party libraries working together, or a language feature.

You will notice that READMEs and guides are not source code files, but are 
valuable parts of the hierarchical documentation system.

-- 
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: contentEditable and caret jumps

[Lars Jacobsson]

Yeah, the problem is that when we are talking about contentEditable divs and 
spans there is no "defaultValue" attribute!

-- 
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] How to use Dict.empty?

[Max Goldstein]

It would be helpful if you showed us more context, including the definitions of 
your record type aliases.

-- 
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] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Duane Johnson]

I think this list is for discussion and is not as frequented by the elm
core developers, so you might try
https://groups.google.com/forum/?fromgroups#!forum/elm-dev

They still show up here on occasion, but my impression is that they
primarily hang out over there.

On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie 
wrote:

> I've noticed a fair amount of discussion around various shortcomings of
> Elm's native libraries. Particular examples that affect me are the limited
> Websocket API and no native typed-array implementation.  The former is
> limits me quite a bit, while the latter is simply a nice-to-have. I've seen
> clamoring for file upload support as well. In any event, it would be
> interesting to get an idea of what people feel are the Elm's biggest
> shortcomings in terms of natively supported features.
>
> One thing that is frustrating as an Elm user is feeling in the dark when
> it comes to feature requests. I know the team likes to batch their efforts,
> but it's disheartening to see something sit for months unanswered. I'm
> hoping for two things to come out of this post: Get an idea of what the
> biggest pain points are in terms of natively supported API's, and to get an
> idea of what the Elm devs think. Any feedback really would be nice!
>
> Brian
>
> --
> 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.
>

-- 
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] elm-lang/Navigation with hash and query string

[Charlie Koster]

I think I came up with a workable solution by adding a tiny bit of 
abstraction.

import Html exposing (Attribute, Html, a)
import Html.Events exposing (onWithOptions, defaultOptions)
import Model exposing (Msg(..))
import Json.Decode as Json


link : String -> List (Attribute Msg) -> List (Html Msg) -> Html Msg
link route attributes children =
let
clickHandler =
onWithOptions "click" defaultOptions <| Json.succeed <| 
NavigateTo route

attrs =
clickHandler :: attributes
in
a
attrs
children

What this allows me to do is replace these:

a [ onClick (NavMsg1 param1), class "some class", title "Do something" ] [ 
text "Do something" ]
a [ onClick (NavMsg2), title "Do something else" ] [ text "Dom something 
else" ]
a [ onClick (NavMsg3 param2 param3), class "is-disabled", title "Delete 
thing" ] [ text "Delete thing" ]

..which has a lot of custom Msgs (one Msg per route).. and replace it with

link ("/something?param1=" ++ param1) [ class "some class", title "Do 
something" ] [ text "Do something" ]
link ("/home") [ title "Do something else" ] [ text "Dom something else" ]
link ("/deletePage?param2=" ++ param2 ++ "=" ++ param3) [ class 
"is-disabled", title "Delete thing" ] [ text "Delete thing" ]

The above reads very similar to using an anchor tag with an href attribute 
which is what I was hoping for.

Additionally, just as with your solution, there is only one Msg for going 
to the different pages rather than a unique Msg for every different page.

-- 
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] elm-lang/Navigation with hash and query string

[Nicolas Artman]

Yep, it's standard complaint as Nick said. This behavior also agrees with
the routing behavior for most JS client stacks I've used as well.
On Fri, Dec 9, 2016 at 6:06 PM Nick H  wrote:

> I would call this not a bug, since it conforms to the URL standard
> . in your second example,
> ?a=b=d is not a query string, but a part of the fragment string.
>
> This is just one of several ways that URL syntax can lead you down a dark
> alley and steal your wallet.
>
> On Fri, Dec 9, 2016 at 5:53 PM, Charlie Koster 
> wrote:
>
> I submitted an issue
>  to
> evancz/url-parser but it ended up being human error on my part. However,
> I'm making this post because of my closing comment
> 
> on that issue.
>
> To summarize, I'm using `UrlParser.parseHash` along with `Url.stringParam`
> and I can't get that parser to work. After some digging I noticed that
> elm-lang/Navigation is providing me a `Location` that doesn't have a search
> attribute. Here are two examples.
>
> Navigate to http://localhost:8080*/test?a=b=d*
> Logging the Location gives me:
> { href = "http://localhost:8080/test?a=b=d;, host = "localhost:8080",
> hostname = "localhost", protocol = "http:", origin = "
> http://localhost:8080;, port_ = "8080", pathname = "/test", search =
> "?a=b=d", hash = "", username = , password = <
> internal structure> }
>
> Notice the search attribute as my query string.
>
> Navigate to http://localhost:8080*/#test?a=b=d*
> Logging the Location gives me:
> { href = "http://localhost:8080/#test?a=b=d;, host = "localhost:8080",
> hostname = "localhost", protocol = "http:", origin = "
> http://localhost:8080;, port_ = "8080", pathname = "/", search = "", hash
> = "#test?a=b=d", username = , password =  structure> }
>
> Notice the search attribute is an empty string and the hash attribute
> contains both the hash and the query string
>
> My question to the community.. Is this a bug with elm-lang/Navigation,
> evancz/url-parser, or not a bug at all because that's how hashes work and I
> have to deal with this manually?
>
> --
> 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.
>
>
> --
> 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.
>

-- 
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 do I make a port that doesn't take an argument?

[Kevin Yank]

Yup. I’m another confused soul who found his answer here after the error 
message pointed to the docs that did not cover this limitation.

On Tuesday, June 7, 2016 at 10:21:39 PM UTC+10, Tim Stewart wrote:
>
> This caught me out the other day too, so if it's not going to be added on 
> a whim it could at least be noted as a limitation. Particularly seeing as 
> the error message gives a URL to a doc page ... which has no mention of 
> this. Triggering an action in JS that takes no parameters seems like a 
> valid use case though.
>
> On Monday, June 6, 2016 at 1:11:50 PM UTC+10, Max Goldstein wrote:
>>
>>  This is not about subscribers, it's for sending out to the JavaScript.
>>>
>>
>> A "subscriber" is the name of the JS function that handles the value sent 
>> from Elm. As in, app.ports.fetch.subscribe. But yes, it's not about 
>> *subscriptions*. Maybe we need a name change...
>>
>> I don't think it's a bug so much as an unsupported feature. Subscribers 
>> always get passed a value, and you need to send that value from Elm. You 
>> can write your JS functions to ignore the argument, but it needs to be done 
>> in Elm nonetheless.
>>
>> Mind you, I don't think allowing ports as commands with no arguments 
>> would be a bad change, but it's not going to be added on a whim.
>>
>

-- 
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] elm-lang/Navigation with hash and query string

[Nicolas Artman]

Standards *compliant. Sorry about the typo.
On Sat, Dec 10, 2016 at 12:08 PM Nicolas Artman  wrote:

> Yep, it's standard complaint as Nick said. This behavior also agrees with
> the routing behavior for most JS client stacks I've used as well.
> On Fri, Dec 9, 2016 at 6:06 PM Nick H  wrote:
>
> I would call this not a bug, since it conforms to the URL standard
> . in your second example,
> ?a=b=d is not a query string, but a part of the fragment string.
>
> This is just one of several ways that URL syntax can lead you down a dark
> alley and steal your wallet.
>
> On Fri, Dec 9, 2016 at 5:53 PM, Charlie Koster 
> wrote:
>
> I submitted an issue
>  to
> evancz/url-parser but it ended up being human error on my part. However,
> I'm making this post because of my closing comment
> 
> on that issue.
>
> To summarize, I'm using `UrlParser.parseHash` along with `Url.stringParam`
> and I can't get that parser to work. After some digging I noticed that
> elm-lang/Navigation is providing me a `Location` that doesn't have a search
> attribute. Here are two examples.
>
> Navigate to http://localhost:8080*/test?a=b=d*
> Logging the Location gives me:
> { href = "http://localhost:8080/test?a=b=d;, host = "localhost:8080",
> hostname = "localhost", protocol = "http:", origin = "
> http://localhost:8080;, port_ = "8080", pathname = "/test", search =
> "?a=b=d", hash = "", username = , password = <
> internal structure> }
>
> Notice the search attribute as my query string.
>
> Navigate to http://localhost:8080*/#test?a=b=d*
> Logging the Location gives me:
> { href = "http://localhost:8080/#test?a=b=d;, host = "localhost:8080",
> hostname = "localhost", protocol = "http:", origin = "
> http://localhost:8080;, port_ = "8080", pathname = "/", search = "", hash
> = "#test?a=b=d", username = , password =  structure> }
>
> Notice the search attribute is an empty string and the hash attribute
> contains both the hash and the query string
>
> My question to the community.. Is this a bug with elm-lang/Navigation,
> evancz/url-parser, or not a bug at all because that's how hashes work and I
> have to deal with this manually?
>
> --
> 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.
>
>
> --
> 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.
>
>

-- 
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] elm-lang/Navigation with hash and query string

[Charlie Koster]

Thanks for the response, Magnus.

If I'm understanding correctly, you have a parent div that prevents default 
click events of child elements, including your anchor tag, and turns them 
into `Attribute msg`.

Your solution is interesting, although it looks like a fair amount of 
boilerplate and work arounds and I'm trying to avoid both.

It might be worthwhile for me to dig through some of the popular JS 
frameworks routing source code to see how they solve this problem. 
AngularJS solves this with a custom href attribute called ui-sref. Maybe a 
custom attribute is the answer for Elm too?

-- 
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] elm-lang/Navigation with hash and query string

[Magnus Rundberget]

You could do something like this:
https://github.com/rundis/albums/blob/master/frontend/src/Routes.elm#L84
Use it like this 
https://github.com/rundis/albums/blob/master/frontend/src/ArtistListing.elm#L100
And wire it up like this.
https://github.com/rundis/albums/blob/master/frontend/src/Main.elm#L96
And https://github.com/rundis/albums/blob/master/frontend/src/Main.elm#L136

Cheers
-magnus

-- 
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] contentEditable and caret jumps

[Lars Jacobsson]

I've got a problem. We need to use contentEditable elements and while 
editing them, the caret jumps to the beginning of the box everytime the 
model updates. This derives from the fact that the browser holds some state 
about the caret position outside the model (the horror), and we reset that 
brower caret state everytime we update.

There are ways to solve this by talking to js using textranges (eg. here 
), but I look at that as an implementational 
nightmare with possible performance implications and shaky browser support.

Since it is just a fact of life that the browser holds some state, I'd like 
to handle it by intentionally putting the Dom and the model temporarily out 
of sync. Meaning that when the model updates, virtual dom won't update the 
element we are currently editing.

However - and this is crucial - I still want to update the model onInput 
(practically meaning on every new character entered). I just don't want 
virutal dom to update the element then the new data hits the view.

Is there any way of telling Elm to not update an element (ie essentially do 
what shouldComponentUpdate does in React)?

-- 
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.