Re: [elm-discuss] Re: Upgrading to 0.18 and elm-webpack-starter

[Noah Hall]

FWIW there's a patch I've been working on to make change detection
more consistent. I'll release it as 4.1.2 soon

On Fri, Dec 23, 2016 at 6:34 AM, Nathan Eldridge  wrote:
> I'm not certain of your configuration, but in our current project we pretty
> much use the standard:
>
> // This loader can be in commonConfig or the production/development section
> seperately.
>
> module: {
>  loaders: [
> {
> test: /\.elm$/,
> exclude: [/elm-stuff/, /node_modules/],
> loader: 'elm-hot!elm-webpack'
>
> }
> // our other loaders here
> ]};
>
>
> I assume that's your loader. In your package.json, you should have something
> like
>
> "devDependencies":{
> "elm": "^0.18.0",
> "elm-hot-loader": "^0.5.4",
> "elm-webpack-loader": "^4.1.1",
> "webpack": "^1.14.0",
> "webpack-dev-server": "^1.16.2",
> "webpack-merge": "^2.0.0"
> //just an example of the basic required packages
> }
>
> The above is what I can look at on a personal project where I have upgraded
> those modules manually without issue. The rest of the packages are the same
> as the starter with the exception of a few tweaks to change from bootstrap
> to semantic-ui, and I guess less-loader.
>
> If you're just using the standard elm-webpack-starter, then you should only
> need to set it as a query on the loader. I personally just installed the
> 0.18 package globally from the executable from elm-lang.org. If you don't
> want to do that, then just edit your loader so that it looks like this:
>
> //for development build
>
> {
> test: /\.elm$/,
> exclude: [/elm-stuff/, /node_modules/],
> loader: 'elm-hot!elm-webpack?pathToMake=node_modules/.bin/elm-make'
>
> }
>
> //for production build
>
> {
> test: /\.elm$/,
> exclude: [/elm-stuff/, /node_modules/],
> loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make'
>
> }
>
> Just double check and see that your packages were installed/upgraded through
> npm. I can't tell you how often I frustrate myself when I decide to upgrade
> a package for a new feature/bug fix and I continue to expect it to work
> without having actually done anything besides save the package change in
> package.json.
>
> The only other thing that I can think of that could be an issue is if you
> have globally installed 0.17 and that package is not upgraded to 0.18.
>
> Because I don't remember npm commands, the quick reference would just be
>
> npm upgrade -g elm
>
> That assumes you are using npm 3+ rather than installing the executable from
> the elm-lang website.
>
>
> As for what Martin and Simon have said, I've noticed that elm-hot-loader
> only seems to catch your top level changes. Basically, it requires that your
> file structure be flat to pick up changes consistently. Was that your
> experience? I would love for elm-hot-loader to catch a few nested folders we
> have, but playing around with the configuration didn't seem to help.
>
>
>
> On Thursday, December 22, 2016 at 12:41:44 PM UTC-6, Rex van der Spuy wrote:
>>
>>
>>>  It's possible that your elm-webpack-loader is pointing to the wrong
>>> executable.
>>
>>
>> Thanks Nathan! Everything else seem fine so it seems that this is likely
>> the problem.
>> Do you know where this needs to be set?
>> I noticed this from the README in elm-webpack-loader but I wasn't sure
>> where or how it should be set (in webpack.config.js?)
>>
>> ```
>> All options are sent down as an `options` object to node-elm-compiler. For
>> example, you can explicitly pick the local `elm-make` binary by setting the
>> option `pathToMake`:
>>
>> ```js
>>   ...
>>   loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make',
>>   ...
>> ```
>>
>
> --
> 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: Upgrading to 0.18 and elm-webpack-starter

[Nathan Eldridge]

I'm not certain of your configuration, but in our current project we pretty 
much use the standard: 

// This loader can be in commonConfig or the production/development section 
seperately.

module: {
 loaders: [
{
test: /\.elm$/,
exclude: [/elm-stuff/, /node_modules/],
loader: 'elm-hot!elm-webpack'

}
// our other loaders here
]};


I assume that's your loader. In your package.json, you should have 
something like 

"devDependencies":{
"elm": "^0.18.0",
"elm-hot-loader": "^0.5.4",
"elm-webpack-loader": "^4.1.1",
"webpack": "^1.14.0",
"webpack-dev-server": "^1.16.2",
"webpack-merge": "^2.0.0"
//just an example of the basic required packages
}

The above is what I can look at on a personal project where I have upgraded 
those modules manually without issue. The rest of the packages are the same 
as the starter with the exception of a few tweaks to change from bootstrap 
to semantic-ui, and I guess less-loader.

If you're just using the standard elm-webpack-starter, then you should only 
need to set it as a query on the loader. I personally just installed the 
0.18 package globally from the executable from elm-lang.org. If you don't 
want to do that, then just edit your loader so that it looks like this:

//for development build

{
test: /\.elm$/,
exclude: [/elm-stuff/, /node_modules/],
loader: 'elm-hot!elm-webpack?pathToMake=node_modules/.bin/elm-make'

}

//for production build

{
test: /\.elm$/,
exclude: [/elm-stuff/, /node_modules/],
loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make'

}

Just double check and see that your packages were installed/upgraded 
through npm. I can't tell you how often I frustrate myself when I decide to 
upgrade a package for a new feature/bug fix and I continue to expect it to 
work without having actually done anything besides save the package change 
in package.json.

The only other thing that I can think of that could be an issue is if you 
have globally installed 0.17 and that package is not upgraded to 0.18.

Because I don't remember npm commands, the quick reference would just be

npm upgrade -g elm

That assumes you are using npm 3+ rather than installing the executable 
from the elm-lang website.


As for what Martin and Simon have said, I've noticed that elm-hot-loader 
only seems to catch your top level changes. Basically, it requires that 
your file structure be flat to pick up changes consistently. Was that your 
experience? I would love for elm-hot-loader to catch a few nested folders 
we have, but playing around with the configuration didn't seem to help.



On Thursday, December 22, 2016 at 12:41:44 PM UTC-6, Rex van der Spuy wrote:

>
>  It's possible that your elm-webpack-loader is pointing to the wrong 
>> executable.
>>
>  
> Thanks Nathan! Everything else seem fine so it seems that this is likely 
> the problem. 
> Do you know where this needs to be set? 
> I noticed this from the README in elm-webpack-loader but I wasn't sure 
> where or how it should be set (in webpack.config.js?)
>
> ```
> All options are sent down as an `options` object to node-elm-compiler. For 
> example, you can explicitly pick the local `elm-make` binary by setting the 
> option `pathToMake`:
>
> ```js
>   ...
>   loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make',
>   ...
> ```
>  
>

-- 
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: Our little, failed Elm 0.18 deployment

[Max Goldstein]

If you have a polyfill to fix a 17 -> 18 regression, you should make a pull 
request to core, or at least write up a blog post explaining the problem and 
solution. 

-- 
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: Our little, failed Elm 0.18 deployment

[Witold Szczerba]

Little backup: while I was preparing for writing a 0.17 port of the app, my 
colleague 
told me about his finding that the problem is related to 
the Window.requestAnimationFrame(). He was working on a fix and I was 
looking for a workaround and as far as I can see we've both succeeded. His 
pull-request looks like a proper fix and the RAF polyfill, when applied, 
also makes the application work on old browsers. Lucky us! :)

On Thursday, December 22, 2016 at 11:01:52 PM UTC+1, Witold Szczerba wrote:
>
> Hi there,
> Maybe some of you are where I was while ago, thinking about introducing 
> Elm to a production system. The small (tiny) app, ideal for trying 
> something new. 
>
> The problem is we didn't actually check if it does work with all browsers 
> our customers use and we've got the hard lesson soon after deployment when 
> support center started reporting issues.
>
> So, as of now Elm 0.18 crashes on IE9 (not a  real problem) but also on 
> Android phones with old Chrome (like 18) or stock Android 4.1 browsers (and 
> maybe some newer ones as well).
>
> Yesterday we applied New Relic and it constantly report the 
> https://github.com/elm-lang/virtual-dom/issues/55 error because of those 
> Android users. 
>
> The good thing is I can still prevent removal of Elm if I port the app to 
> 0.17 as it looks it should work OK. I'm going to find my old phone first :)
>
> So, the bottom line is if some of you are porting to 0.18, beware of that 
> bug until it's fixed and if you are working on new app, check by yourself 
> if it's going to work for all your customers :)
>
> Regards,
> Witold Szczerba
>
>
>
>

-- 
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: Elm-make freezes !

[Murphy Randle]

I just had a similar thing happen. Try removing elm-stuff, and then running 
`elm-package install` *first* before you run `elm-make`. That seemed to fix 
it for me.

On Tuesday, December 13, 2016 at 7:28:15 AM UTC-7, Sébastien FLOURE wrote:
>
> frozen at 92/156 !
>
>
> Any log available ? any idea how to fix that ?
>
>
> 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] Our little, failed Elm 0.18 deployment

[Witold Szczerba]

Hi there,
Maybe some of you are where I was while ago, thinking about introducing Elm
to a production system. The small (tiny) app, ideal for trying something
new.

The problem is we didn't actually check if it does work with all browsers
our customers use and we've got the hard lesson soon after deployment when
support center started reporting issues.

So, as of now Elm 0.18 crashes on IE9 (not a  real problem) but also on
Android phones with old Chrome (like 18) or stock Android 4.1 browsers (and
maybe some newer ones as well).

Yesterday we applied New Relic and it constantly report the
https://github.com/elm-lang/virtual-dom/issues/55 error because of those
Android users.

The good thing is I can still prevent removal of Elm if I port the app to
0.17 as it looks it should work OK. I'm going to find my old phone first :)

So, the bottom line is if some of you are porting to 0.18, beware of that
bug until it's fixed and if you are working on new app, check by yourself
if it's going to work for all your customers :)

Regards,
Witold Szczerba

-- 
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: Upgrading to 0.18 and elm-webpack-starter

[Martin DeMello]

I've never had webpack file watching work robustly for me. I finally just
bound a vim hotkey to "touch Main.elm" which was an adequate workaround.

martin

On Thu, Dec 22, 2016 at 9:50 AM, Simon  wrote:

> I just updated my skeleton app using webpack to 0.18. There was a bug in
> elm-webpack-loader but that has now been fixed.
>
> See https://github.com/simonh1000/elm-hot-loader for details
>
> (I am seeing the watching breaking after 5 or so rebuilds, which is a bit
> frustrating. I had that before and returned to gulp because of it. If
> anyone knows how to make webpack file watching more robust, let me know)
>
>
>
>
> On Thursday, 22 December 2016 18:39:20 UTC+1, Nathan Eldridge wrote:
>>
>> I know this is a pretty obvious solution, but have you doubled checked
>> your package.json file? My current project started with elm-webpack-starter
>> with several tweaks. When I ran elm-upgrade it did skip over that.
>>
>> You could also be trying to use an installed version of elm-make instead
>> of the package.json version. In an earlier iteration of my current project,
>> I managed to screw around with the path variables too much on Windows and
>> did that as well.
>>
>> If the obvious didn't fix it, are you using the standard 0.17
>> webpack.config.js file? It's possible that your elm-webpack-loader is
>> pointing to the wrong executable.
>>
>>
>> On Thursday, December 22, 2016 at 8:58:50 AM UTC-6, Rex van der Spuy
>> wrote:
>>>
>>> Hi Everyone,
>>>
>>> I'm trying to figure out the best way to get my newly upgraded 0.18 code
>>> to work with an existing elm-webpack-starter installation.
>>> My new code works fine in reactor, but elm-webpack-starter is still
>>> trying to compile it as 0.17.
>>>
>>> Can anyone suggest how to turn-on 0.18 compilation in the 0.7.1 version
>>> of elm-webpack-starter?
>>> Or, should I just clone a the latest version, 0.8, (which is
>>> pre-configured for 0.18) and copy my upgraded Elm source code into it?
>>>
>> --
> 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: Web Components in Elm

['Rupert Smith' via Elm Discuss]

Also, some native code is needed to allow one Elm Program to include 
another as a web component. Internally to Elm it looks like swapping events 
between two Programs, but 'natively' beneath this, the included component 
would be a 'web component' meeting the spec.

On Thursday, December 22, 2016 at 7:51:49 PM UTC, Rupert Smith wrote:
>
> On Thursday, December 22, 2016 at 12:26:09 PM UTC, Peter Damoc wrote:
>>
>> Has any of you attempted to implement a web components system for Elm? 
>>
>> What I'm looking for is a exploration that allows for web components to 
>> be defined in Elm with the help of some kind of Native module. 
>> In other words, I'm looking for automation of the process, something that 
>> would allow the definition and use of web components without touching JS. 
>> *Is 
>> this even possible?* 
>>
>> If you haven't implemented anything but have thought about this, could 
>> you share your ideas about how would one go about implementing this? 
>>
>
> After playing around with different Program types for static Html 
> rendering  server side, I still think introducing a new native Program type 
> for web component is an approach worth exploring. 
>
> Each Elm program can be a unit encapsulating some state. It would be 
> further ellaborated than a regular Program, as this Program type would also 
> be able to expose some out messages and in messages. It would re-use flags 
> for setting up the component by passing in an input data model. The data 
> model that it exposes to the outside would not have to be the same as the 
> state model it holds internally. In this way, an Elm Program becomes a 
> component with private internal state, just like a web component.
>
> This Program would be implemented in a native module, following the style 
> in which Html.program is. Build up whatever else is needed on the 
> javascript side to make this a web component.
>
> It doesn't fit right with Elm, this idea of encapsulating private internal 
> state, and that is part of what makes working in Elm difficult for those of 
> us coming from an imperative OO background. Still, if forming a component 
> out of some Elm code were to be done, I think the Program feels like the 
> right level of abstraction to do it.
>

-- 
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: Web Components in Elm

['Rupert Smith' via Elm Discuss]

On Thursday, December 22, 2016 at 12:26:09 PM UTC, Peter Damoc wrote:
>
> Has any of you attempted to implement a web components system for Elm? 
>
> What I'm looking for is a exploration that allows for web components to be 
> defined in Elm with the help of some kind of Native module. 
> In other words, I'm looking for automation of the process, something that 
> would allow the definition and use of web components without touching JS. *Is 
> this even possible?* 
>
> If you haven't implemented anything but have thought about this, could you 
> share your ideas about how would one go about implementing this? 
>

After playing around with different Program types for static Html rendering 
 server side, I still think introducing a new native Program type for web 
component is an approach worth exploring. 

Each Elm program can be a unit encapsulating some state. It would be 
further ellaborated than a regular Program, as this Program type would also 
be able to expose some out messages and in messages. It would re-use flags 
for setting up the component by passing in an input data model. The data 
model that it exposes to the outside would not have to be the same as the 
state model it holds internally. In this way, an Elm Program becomes a 
component with private internal state, just like a web component.

This Program would be implemented in a native module, following the style 
in which Html.program is. Build up whatever else is needed on the 
javascript side to make this a web component.

It doesn't fit right with Elm, this idea of encapsulating private internal 
state, and that is part of what makes working in Elm difficult for those of 
us coming from an imperative OO background. Still, if forming a component 
out of some Elm code were to be done, I think the Program feels like the 
right level of abstraction to do it.

-- 
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: Upgrading to 0.18 and elm-webpack-starter

[Rex van der Spuy]

 It's possible that your elm-webpack-loader is pointing to the wrong 
> executable.
>
 
Thanks Nathan! Everything else seem fine so it seems that this is likely 
the problem. 
Do you know where this needs to be set? 
I noticed this from the README in elm-webpack-loader but I wasn't sure 
where or how it should be set (in webpack.config.js?)

```
All options are sent down as an `options` object to node-elm-compiler. For 
example, you can explicitly pick the local `elm-make` binary by setting the 
option `pathToMake`:

```js
  ...
  loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make',
  ...
```
 

-- 
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] Faster subscription logic: A thought

[Mark Hamburg]

When I look at applications I've built in the past and the parts of them
that would naturally be represented using subscriptions — e.g.,
subscriptions for image status (or even image data) on a grid of images — I
worry about how well they scale. In particular:

* As I understand it, subscriptions is called after every cycle through
update. This makes it a potential point of significant expense if the work
load is significant. This might not be essential, but if there is a
guarantee that if the current state of a model does not return a
subscription then the model will not receive messages from subscriptions
established by earlier states of the model, then it probably is essential.

* The subscriptions function has to operate on all parts of the model that
can generate subscriptions.

* The effects manager code has to diff the lists of subscriptions provided
to it. This results in a trend toward subscriptions having globally unique
identifiers which can be awkward/expensive if there is any nesting. (See,
for example, Http.Progress.)

So, subscriptions are calculated often, have a cost when calculated
proportional to the model size (in general), and then require a way to
efficiently diff them in the effects managers.

This sounds a lot like what happens with views and we know that Elm has a
very fast view system. (There are blog posts that say so!) So, what if
subscriptions borrowed a bit more from views:

• Sub.batch is essentially the equivalent of creating a parent node.

• Sub.map is essentially the equivalent of Html.map

• We could add Sub.Lazy as a way to avoid recomputing subscriptions

• Sub.Keyed or Sub.keyedBatch could also help with subscriptions coming and
going

• The diff could be computed by the same tree diff logic that would make
Sub.Lazy work and could report new subscriptions and subscriptions that
were going away and possibly "changed" subscriptions if we had an idea of
such a thing.

Put this together and the compute costs for subscriptions become
proportional to the size of changes to the model as opposed to to the model
size and effects managers don't need to do as much book keeping themselves.
This should make it more palatable to update subscriptions frequently.

Turning back to my photos example, this would, for example mean that I
could structure the logic so that computing subscriptions looks at the
portion of the photo grid that is visible and generates a subscription
keyed by photo_id for each visible photo. These subscriptions are generated
as being lazy themselves so that they don't get
regenerated when a photo stays visible and the diff logic gets to exploit
the fact that they aren't changing:

subscriptions { photoArray, firstVisible, lastVisible } =
Sub.lazy3 subscriptions_ photoArray firstVisible lastVisible

subscriptions_ photoArray firstVisible lastVisible =
   Array.slice firstVisible lastVisible photoArray
   |> Array.map (\photo -> ( photo.id, photoSubscriptions photo )
   |> Array.toList
   |> Sub.keyedBatch

photoSubscriptions photo =
Sub.lazy photoSubscriptions_ photo

etc

Mark

P.S. This example also makes me want Array.sliceMapToList but that's a
different matter. To really be efficient on huge numbers of photos, I would
probably want to use something other than an array.

-- 
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: Upgrading to 0.18 and elm-webpack-starter

[Simon]

I just updated my skeleton app using webpack to 0.18. There was a bug in 
elm-webpack-loader but that has now been fixed.

See https://github.com/simonh1000/elm-hot-loader for details

(I am seeing the watching breaking after 5 or so rebuilds, which is a bit 
frustrating. I had that before and returned to gulp because of it. If 
anyone knows how to make webpack file watching more robust, let me know)




On Thursday, 22 December 2016 18:39:20 UTC+1, Nathan Eldridge wrote:
>
> I know this is a pretty obvious solution, but have you doubled checked 
> your package.json file? My current project started with elm-webpack-starter 
> with several tweaks. When I ran elm-upgrade it did skip over that. 
>
> You could also be trying to use an installed version of elm-make instead 
> of the package.json version. In an earlier iteration of my current project, 
> I managed to screw around with the path variables too much on Windows and 
> did that as well.
>
> If the obvious didn't fix it, are you using the standard 0.17 
> webpack.config.js file? It's possible that your elm-webpack-loader is 
> pointing to the wrong executable.
>
>
> On Thursday, December 22, 2016 at 8:58:50 AM UTC-6, Rex van der Spuy wrote:
>>
>> Hi Everyone,
>>
>> I'm trying to figure out the best way to get my newly upgraded 0.18 code 
>> to work with an existing elm-webpack-starter installation.
>> My new code works fine in reactor, but elm-webpack-starter is still 
>> trying to compile it as 0.17.
>>
>> Can anyone suggest how to turn-on 0.18 compilation in the 0.7.1 version 
>> of elm-webpack-starter?
>> Or, should I just clone a the latest version, 0.8, (which is 
>> pre-configured for 0.18) and copy my upgraded Elm source code into it? 
>>
>

-- 
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 up with elm-mdl?

[Simon]

> all I really need are just grid layouts and buttons with ripple effects

flexbox and e.g. https://ghinda.net/article/css-ripple-material-design/ ?

On Thursday, 22 December 2016 18:42:49 UTC+1, Mike MacDonald wrote:
>
> That looks really nice. Even if one does not wish to use it directly, 
> having examples of reusable ways to make such controls is hugely useful 
> pedagogically.
>
> On Thursday, December 22, 2016 at 9:02:03 AM UTC-5, Dave Rapin wrote:
>>
>> What are your thoughts on elm-ui? I quite like it (prefer it to elm-mdl 
>> actually), and am considering it for a real project. How does it match up 
>> with the current Elm recommendations?
>> http://elm-ui.info/
>>
>>
>> On Thursday, December 22, 2016 at 2:07:29 AM UTC-5, Peter Damoc wrote:
>>>
>>> On Wed, Dec 21, 2016 at 8:02 PM, Rex van der Spuy  
>>> wrote:

 Can anyone explain what's going on?

>>>
>>> I haven't been following elm-mdl lately but maybe I can provide some 
>>> historical context. 
>>>
>>> Reuse of UI is a topic that hasn't been solved in Elm. 
>>> This is why we don't have any official or recommended complex UI toolkit.
>>>
>>> The first real attempt at solving the issue was TEA (The Elm 
>>> Architecture). This was a pattern that was distilled by Evan into the 
>>> elm-architecture-tutorial. 
>>> That tutorial used to show how to define components and how to nest 
>>> them. 
>>>
>>> Unfortunately, as soon as people started using the pattern for real work 
>>> a lot of discussions started to happen about messages flow (OutMsg) and 
>>> some people abused the pattern by splitting the code too much in terms of 
>>> components. 
>>>
>>> Another issue with fancy low level components (many small components 
>>> that are unavoidably stateful) is the amount of boilerplate needed and so, 
>>> Søren created elm-parts that addressed this and then implemented elm-mdl on 
>>> top of that. 
>>> Now, Evan moved away from recommending the nesting architecture and 
>>> advised against putting functions in Model & Msg. This put the 
>>> implementation of elm-mdl at odds with the official recommendation. 
>>>
>>> Polymer and webcomponents represent the latest attempt at exploring the 
>>> UI reuse issue in Elm. 
>>> This attempt is in its infancy. 
>>> Josh said that he will implement Firestorm using webcomponents and since 
>>> that kickstarter got funded we might see a real-world complex use of the 
>>> technology. 
>>>
>>> v1 of the WebComponents standard has been agreed upon by all major 
>>> vendors and I'm optimistic about its availability (I believe we'll see it 
>>> available next year in the evergreens)
>>> Others don't share my optimism and there is also the issue of mandated 
>>> IE support. 
>>>
>>> I guess we'll see what will happen next year. 
>>>
>>> In the end, I would like to say that the situation is so foggy that I 
>>> don't really have a solid recommendation. 
>>> elm-mdl looks like a dead-end while webcomponents is so brand new that 
>>> we still haven't figured out how to use it. 
>>>
>>> The best way forward now might be to use the 0.18 port of elm-mdl with 
>>> the flat hierarchy recommendations from the reuse part of the guide. Choose 
>>> not to block. 
>>> This might allow for an easy refactoring to a better technology. 
>>> (webcomponents) 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> 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] What up with elm-mdl?

[Mike MacDonald]

That looks really nice. Even if one does not wish to use it directly, 
having examples of reusable ways to make such controls is hugely useful 
pedagogically.

On Thursday, December 22, 2016 at 9:02:03 AM UTC-5, Dave Rapin wrote:
>
> What are your thoughts on elm-ui? I quite like it (prefer it to elm-mdl 
> actually), and am considering it for a real project. How does it match up 
> with the current Elm recommendations?
> http://elm-ui.info/
>
>
> On Thursday, December 22, 2016 at 2:07:29 AM UTC-5, Peter Damoc wrote:
>>
>> On Wed, Dec 21, 2016 at 8:02 PM, Rex van der Spuy  
>> wrote:
>>>
>>> Can anyone explain what's going on?
>>>
>>
>> I haven't been following elm-mdl lately but maybe I can provide some 
>> historical context. 
>>
>> Reuse of UI is a topic that hasn't been solved in Elm. 
>> This is why we don't have any official or recommended complex UI toolkit.
>>
>> The first real attempt at solving the issue was TEA (The Elm 
>> Architecture). This was a pattern that was distilled by Evan into the 
>> elm-architecture-tutorial. 
>> That tutorial used to show how to define components and how to nest them. 
>>
>> Unfortunately, as soon as people started using the pattern for real work 
>> a lot of discussions started to happen about messages flow (OutMsg) and 
>> some people abused the pattern by splitting the code too much in terms of 
>> components. 
>>
>> Another issue with fancy low level components (many small components that 
>> are unavoidably stateful) is the amount of boilerplate needed and so, Søren 
>> created elm-parts that addressed this and then implemented elm-mdl on top 
>> of that. 
>> Now, Evan moved away from recommending the nesting architecture and 
>> advised against putting functions in Model & Msg. This put the 
>> implementation of elm-mdl at odds with the official recommendation. 
>>
>> Polymer and webcomponents represent the latest attempt at exploring the 
>> UI reuse issue in Elm. 
>> This attempt is in its infancy. 
>> Josh said that he will implement Firestorm using webcomponents and since 
>> that kickstarter got funded we might see a real-world complex use of the 
>> technology. 
>>
>> v1 of the WebComponents standard has been agreed upon by all major 
>> vendors and I'm optimistic about its availability (I believe we'll see it 
>> available next year in the evergreens)
>> Others don't share my optimism and there is also the issue of mandated IE 
>> support. 
>>
>> I guess we'll see what will happen next year. 
>>
>> In the end, I would like to say that the situation is so foggy that I 
>> don't really have a solid recommendation. 
>> elm-mdl looks like a dead-end while webcomponents is so brand new that we 
>> still haven't figured out how to use it. 
>>
>> The best way forward now might be to use the 0.18 port of elm-mdl with 
>> the flat hierarchy recommendations from the reuse part of the guide. Choose 
>> not to block. 
>> This might allow for an easy refactoring to a better technology. 
>> (webcomponents) 
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> 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] Re: Upgrading to 0.18 and elm-webpack-starter

[Nathan Eldridge]

I know this is a pretty obvious solution, but have you doubled checked your 
package.json file? My current project started with elm-webpack-starter with 
several tweaks. When I ran elm-upgrade it did skip over that. 

You could also be trying to use an installed version of elm-make instead of 
the package.json version. In an earlier iteration of my current project, I 
managed to screw around with the path variables too much on Windows and did 
that as well.

If the obvious didn't fix it, are you using the standard 0.17 
webpack.config.js file? It's possible that your elm-webpack-loader is 
pointing to the wrong executable.


On Thursday, December 22, 2016 at 8:58:50 AM UTC-6, Rex van der Spuy wrote:
>
> Hi Everyone,
>
> I'm trying to figure out the best way to get my newly upgraded 0.18 code 
> to work with an existing elm-webpack-starter installation.
> My new code works fine in reactor, but elm-webpack-starter is still trying 
> to compile it as 0.17.
>
> Can anyone suggest how to turn-on 0.18 compilation in the 0.7.1 version of 
> elm-webpack-starter?
> Or, should I just clone a the latest version, 0.8, (which is 
> pre-configured for 0.18) and copy my upgraded Elm source code into it? 
>

-- 
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: DOM geometry / SVG library

[Fabrice Marchal]

Another example where I don't see how to avoid reading the DOM: to edit an 
SVG text, we put on top a non-resizeable textarea that grows in height as 
the user types. I do that by reading the offsetHeight of the textarea on 
each key 'input'  and adjust the svg. One could compute the text size from 
the font, etc but it feels like re-inventing the wheel :/

On Thursday, December 22, 2016 at 5:44:26 PM UTC+1, Nick H wrote:
>
> Yes, I agree with Rex. The DOM is write-only by design. Going forward, I 
> don't expect there ever to be a generic way to read the DOM... if specific 
> problems come up that absolutely require it, they will be solved by 
> specific APIs, such as in elm-lang/window and elm-lang/dom.
>
> On Thu, Dec 22, 2016 at 5:57 AM, Rex van der Spuy  > wrote:
>
>>
>>  Currently the solution seems to be 1) compute the bounding box manually 
>>> inside the update function whenever the selection  is modified, 2) keep 
>>> the bounding box data in the model and 3) use the bounding box from the 
>>> model when the update function performs other operations on the model (e.g. 
>>> detect if a click is inside).
>>>
>>
>> That's how us game developers do it: all the geometry and position data 
>> is in the model. That data is then used to blindly draw the shapes in the 
>> view.  
>>
>> -- 
>> 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: DOM geometry / SVG library

[Fabrice Marchal]

Thanks! It could be helpful.

On Thursday, December 22, 2016 at 2:53:13 PM UTC+1, Rex van der Spuy wrote:
>
>
>
>
>> 1. Is someone working on an higher-level SVG library than elm-lang/svg ? 
>> Im thinking about support for path intersection, bounding box operations, 
>> etc.
>>
>> I don't know if this is what you're looking for, but it's excellent:
>
>
> http://package.elm-lang.org/packages/MacCASOutreach/graphicsvg/latest/GraphicSVG
>  
>

-- 
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: Visualizing project dependencies

[Justin Mimbs]

Thanks, Wouter! Glad to hear that. I don't plan to take it down (it's 
hosted on Github). I agree, it gives a good overview of a project's 
structure, regardless of its folder structure.

Justin


On Thursday, December 22, 2016 at 5:49:46 AM UTC-5, Wouter In t Velt wrote:
>
> Op donderdag 22 december 2016 07:16:32 UTC+1 schreef Justin Mimbs:
>>
>> To see it, you can play with this example 
>> , showing 
>> dependencies of knewter/time-tracker 
>> . Clicking a module name will 
>> highlight its own dependencies and the modules that depend on it (as well 
>> as the entire subgraph it's connected to). 
>>
>
> This is really cool! So it shows which module imports and is imported by 
> which other modules!
> Nice!
>
> Hope you will keep the demo (with upload) around. This would be a very 
> useful tool to review my own project/ module/ package structure.
>

-- 
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: DOM geometry / SVG library

[Nick H]

Yes, I agree with Rex. The DOM is write-only by design. Going forward, I
don't expect there ever to be a generic way to read the DOM... if specific
problems come up that absolutely require it, they will be solved by
specific APIs, such as in elm-lang/window and elm-lang/dom.

On Thu, Dec 22, 2016 at 5:57 AM, Rex van der Spuy 
wrote:

>
>  Currently the solution seems to be 1) compute the bounding box manually
>> inside the update function whenever the selection  is modified, 2) keep
>> the bounding box data in the model and 3) use the bounding box from the
>> model when the update function performs other operations on the model (e.g.
>> detect if a click is inside).
>>
>
> That's how us game developers do it: all the geometry and position data is
> in the model. That data is then used to blindly draw the shapes in the
> view.
>
> --
> 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] Upgrading to 0.18 and elm-webpack-starter

[Rex van der Spuy]

Hi Everyone,

I'm trying to figure out the best way to get my newly upgraded 0.18 code to 
work with an existing elm-webpack-starter installation.
My new code works fine in reactor, but elm-webpack-starter is still trying 
to compile it as 0.17.

Can anyone suggest how to turn-on 0.18 compilation in the 0.7.1 version of 
elm-webpack-starter?
Or, should I just clone a the latest version, 0.8, (which is pre-configured 
for 0.18) and copy my upgraded Elm source code into it? 

-- 
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] Idea: Wrap up Expect.* functions to make parentheses in elm-test omittable

[Yuji Yamamoto]

*Problem*

The parentheses in elm-test are visually noisy. 

For example:


all : Test all = describe "Unit test examples"
 [ test "Addition" <|
 \() -> -- <= HERE!
 Expect.equal (3 + 7) 10
 , test "String.left" <|
 \() -> -- <= HERE!
 Expect.equal "a" (String.left 1 "abcdefg")
 ]
Year, I know they have an important role to control order of evaluation of test 
codes.
But in fact, I think the role is relatively less important in Elm and elm-test.
Because Elm functions rarely crush by its design.
So we usually *don't have to be warried that the entire test stops by a runtime 
error* in test codes.

Of course, there're a somewhat important problem left:
Entire test codes are evaluated even when testing partially, which slows 
partial test executions.

*Solution*

I found a way to the parentheses *optionally* omittable, inspired by this 
article (in Japanese) .

Make a module like this:

module WrappedExpect -- The name is provisional.
exposing (..)

import Expect

*-- Wrap Expect.* functions which receives () as an argument
equal : a -> a -> () -> Expectation
equal a b _ = Expect.equal a b*

-- When using:

tests : Test
tests =
describe "example suite"
[ test "example test" <| equal "actual" "expected"
]



I think it make writing tests more flexible to provide the module like 
above along with the exisiting Expect. Feel free to comment!

​

-- 
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 up with elm-mdl?

[Dave Rapin]

What are your thoughts on elm-ui? I quite like it (prefer it to elm-mdl 
actually), and am considering it for a real project. How does it match up 
with the current Elm recommendations?
http://elm-ui.info/


On Thursday, December 22, 2016 at 2:07:29 AM UTC-5, Peter Damoc wrote:
>
> On Wed, Dec 21, 2016 at 8:02 PM, Rex van der Spuy  > wrote:
>>
>> Can anyone explain what's going on?
>>
>
> I haven't been following elm-mdl lately but maybe I can provide some 
> historical context. 
>
> Reuse of UI is a topic that hasn't been solved in Elm. 
> This is why we don't have any official or recommended complex UI toolkit.
>
> The first real attempt at solving the issue was TEA (The Elm 
> Architecture). This was a pattern that was distilled by Evan into the 
> elm-architecture-tutorial. 
> That tutorial used to show how to define components and how to nest them. 
>
> Unfortunately, as soon as people started using the pattern for real work a 
> lot of discussions started to happen about messages flow (OutMsg) and some 
> people abused the pattern by splitting the code too much in terms of 
> components. 
>
> Another issue with fancy low level components (many small components that 
> are unavoidably stateful) is the amount of boilerplate needed and so, Søren 
> created elm-parts that addressed this and then implemented elm-mdl on top 
> of that. 
> Now, Evan moved away from recommending the nesting architecture and 
> advised against putting functions in Model & Msg. This put the 
> implementation of elm-mdl at odds with the official recommendation. 
>
> Polymer and webcomponents represent the latest attempt at exploring the UI 
> reuse issue in Elm. 
> This attempt is in its infancy. 
> Josh said that he will implement Firestorm using webcomponents and since 
> that kickstarter got funded we might see a real-world complex use of the 
> technology. 
>
> v1 of the WebComponents standard has been agreed upon by all major vendors 
> and I'm optimistic about its availability (I believe we'll see it available 
> next year in the evergreens)
> Others don't share my optimism and there is also the issue of mandated IE 
> support. 
>
> I guess we'll see what will happen next year. 
>
> In the end, I would like to say that the situation is so foggy that I 
> don't really have a solid recommendation. 
> elm-mdl looks like a dead-end while webcomponents is so brand new that we 
> still haven't figured out how to use it. 
>
> The best way forward now might be to use the 0.18 port of elm-mdl with the 
> flat hierarchy recommendations from the reuse part of the guide. Choose not 
> to block. 
> This might allow for an easy refactoring to a better technology. 
> (webcomponents) 
>
>
>
>
>
>
>
> -- 
> 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] Re: DOM geometry / SVG library

[Rex van der Spuy]

>  Currently the solution seems to be 1) compute the bounding box manually 
> inside the update function whenever the selection  is modified, 2) keep 
> the bounding box data in the model and 3) use the bounding box from the 
> model when the update function performs other operations on the model (e.g. 
> detect if a click is inside).
>

That's how us game developers do it: all the geometry and position data is 
in the model. That data is then used to blindly draw the shapes in the 
view.  

-- 
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: DOM geometry / SVG library

[Rex van der Spuy]

> 1. Is someone working on an higher-level SVG library than elm-lang/svg ? 
> Im thinking about support for path intersection, bounding box operations, 
> etc.
>
> I don't know if this is what you're looking for, but it's excellent:

http://package.elm-lang.org/packages/MacCASOutreach/graphicsvg/latest/GraphicSVG
 

-- 
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 up with elm-mdl?

[Rex van der Spuy]

Peter, as usual, a brilliant and lucid explanation!!!
Thanks so much for patiently summarizing all this, it makes perfect sense.

So I wonder now what I should do?

- elm-mdl?: 
Looks like it might die on the vine, and the fork many not survive another 
Elm version bump.

- web components and Polymer?:
It's a risky dependency, hacky to implement, and very possibly another dead 
end in the long term.

But, all I really need are just grid layouts and buttons with ripple 
effects :)
Maybe I should just stick to a plain vanilla css file (bootstrap? mdl? 
picnic?) and just add styling with classes?
Boring, but risk-free!

I've got 5 "production" projects using elm-mdl and as I'm bumping them all 
to 0.18 I need to decide now which path I should take.
What would all of you reading this recommend I do?

-- 
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 in Elm

[Peter Damoc]

Has any of you attempted to implement a web components system for Elm?

What I'm looking for is a exploration that allows for web components to be
defined in Elm with the help of some kind of Native module.
In other words, I'm looking for automation of the process, something that
would allow the definition and use of web components without touching JS. *Is
this even possible?*

If you haven't implemented anything but have thought about this, could you
share your ideas about how would one go about implementing this?



-- 
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] type vs type alias

[Will White]

See 
also 
http://faq.elm-community.org/#what-is-the-difference-between-type-and-type-alias.

On Monday, December 19, 2016 at 12:24:50 AM UTC, Joey Eremondi wrote:
>
> Use type alias when you want an abbreviation for a long type name. If you 
> don't want to write List (Dict String SomeVal) over and over again, you can 
> make a type alias to shorten it.
>
> Use a type alias to give a name to record types, and this also gives you a 
> nice shorthand constructor. If you do
>   type alias P2D = {x : Float, y : Float}
> then you can do 
>   P2D 0.0 1.0
> as equivalent to
>   {x = 0.0, y = 1.0}
> and it saves you the effort of writing the literal record type over and 
> over again.
>
> Use a type when you want to create a new type, that's distinct in the 
> compiler. So if you want to distinguish FileName from String, you can make 
> a type, and this will ensure that you have to tag any strings with FileName 
> to use them where a FileName is expected.
>
> And, if you want to define constructors and variants for your type (i.e. a 
> tagged union), or do anything with recursive types, use type, since type 
> alias doesn't allow this.
>
> Why not use *type* everywhere? 
>>
>
> Because then you would have to pattern match every time you used an alias 
> for something, and if you don't want the two types to be distinct in the 
> compiler, then that's a lot of overhead with no benefit. 
>
> On Sun, Dec 18, 2016 at 3:57 PM, Richard Haven <
> richar...@santacruzsoftware.com > wrote:
>
>> When should one use *type *and when should one use *type alias*? Why not 
>> use *type* everywhere? 
>>
>> -- 
>> 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: (Elm logo license.)I want to make Elm logo stickers and distribute them

[Will White]

If part of the purpose is to raise Elm's profile with people who haven't 
seen the logo before then I'd suggest including "Elm" or "elm-lang" in the 
sticker too, so they have something to look up if they don't ask you what 
it is.

On Sunday, December 18, 2016 at 11:55:14 PM UTC, hsw wrote:
>
>
> Hello, 
> I have a question about the Elm logo license.
> I want to print logo as a sticker and distribute it . Does this violate 
> the license?
>
> ・I will explain that it is Elm's logo.
> ・Free.
> ・It is the following two logos.
>
>
> 
>
>
> 
>
>

-- 
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: Visualizing project dependencies

[Wouter In t Velt]

Op donderdag 22 december 2016 07:16:32 UTC+1 schreef Justin Mimbs:
>
> To see it, you can play with this example 
> , showing 
> dependencies of knewter/time-tracker 
> . Clicking a module name will 
> highlight its own dependencies and the modules that depend on it (as well 
> as the entire subgraph it's connected to). 
>

This is really cool! So it shows which module imports and is imported by 
which other modules!
Nice!

Hope you will keep the demo (with upload) around. This would be a very 
useful tool to review my own project/ module/ package structure.

-- 
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 up with elm-mdl?

[Simon]

Would be great if elm-mdl became the next target for Evan's API video 
series

Simon

 

On Thursday, 22 December 2016 11:40:56 UTC+1, Simon wrote:
>
> This is a brilliant post!
>
> On Thursday, 22 December 2016 08:07:29 UTC+1, Peter Damoc wrote:
>>
>> On Wed, Dec 21, 2016 at 8:02 PM, Rex van der Spuy  
>> wrote:
>>>
>>> Can anyone explain what's going on?
>>>
>>
>> I haven't been following elm-mdl lately but maybe I can provide some 
>> historical context. 
>>
>> Reuse of UI is a topic that hasn't been solved in Elm. 
>> This is why we don't have any official or recommended complex UI toolkit.
>>
>> The first real attempt at solving the issue was TEA (The Elm 
>> Architecture). This was a pattern that was distilled by Evan into the 
>> elm-architecture-tutorial. 
>> That tutorial used to show how to define components and how to nest them. 
>>
>> Unfortunately, as soon as people started using the pattern for real work 
>> a lot of discussions started to happen about messages flow (OutMsg) and 
>> some people abused the pattern by splitting the code too much in terms of 
>> components. 
>>
>> Another issue with fancy low level components (many small components that 
>> are unavoidably stateful) is the amount of boilerplate needed and so, Søren 
>> created elm-parts that addressed this and then implemented elm-mdl on top 
>> of that. 
>> Now, Evan moved away from recommending the nesting architecture and 
>> advised against putting functions in Model & Msg. This put the 
>> implementation of elm-mdl at odds with the official recommendation. 
>>
>> Polymer and webcomponents represent the latest attempt at exploring the 
>> UI reuse issue in Elm. 
>> This attempt is in its infancy. 
>> Josh said that he will implement Firestorm using webcomponents and since 
>> that kickstarter got funded we might see a real-world complex use of the 
>> technology. 
>>
>> v1 of the WebComponents standard has been agreed upon by all major 
>> vendors and I'm optimistic about its availability (I believe we'll see it 
>> available next year in the evergreens)
>> Others don't share my optimism and there is also the issue of mandated IE 
>> support. 
>>
>> I guess we'll see what will happen next year. 
>>
>> In the end, I would like to say that the situation is so foggy that I 
>> don't really have a solid recommendation. 
>> elm-mdl looks like a dead-end while webcomponents is so brand new that we 
>> still haven't figured out how to use it. 
>>
>> The best way forward now might be to use the 0.18 port of elm-mdl with 
>> the flat hierarchy recommendations from the reuse part of the guide. Choose 
>> not to block. 
>> This might allow for an easy refactoring to a better technology. 
>> (webcomponents) 
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> 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] What up with elm-mdl?

[Simon]

This is a brilliant post!

On Thursday, 22 December 2016 08:07:29 UTC+1, Peter Damoc wrote:
>
> On Wed, Dec 21, 2016 at 8:02 PM, Rex van der Spuy  > wrote:
>>
>> Can anyone explain what's going on?
>>
>
> I haven't been following elm-mdl lately but maybe I can provide some 
> historical context. 
>
> Reuse of UI is a topic that hasn't been solved in Elm. 
> This is why we don't have any official or recommended complex UI toolkit.
>
> The first real attempt at solving the issue was TEA (The Elm 
> Architecture). This was a pattern that was distilled by Evan into the 
> elm-architecture-tutorial. 
> That tutorial used to show how to define components and how to nest them. 
>
> Unfortunately, as soon as people started using the pattern for real work a 
> lot of discussions started to happen about messages flow (OutMsg) and some 
> people abused the pattern by splitting the code too much in terms of 
> components. 
>
> Another issue with fancy low level components (many small components that 
> are unavoidably stateful) is the amount of boilerplate needed and so, Søren 
> created elm-parts that addressed this and then implemented elm-mdl on top 
> of that. 
> Now, Evan moved away from recommending the nesting architecture and 
> advised against putting functions in Model & Msg. This put the 
> implementation of elm-mdl at odds with the official recommendation. 
>
> Polymer and webcomponents represent the latest attempt at exploring the UI 
> reuse issue in Elm. 
> This attempt is in its infancy. 
> Josh said that he will implement Firestorm using webcomponents and since 
> that kickstarter got funded we might see a real-world complex use of the 
> technology. 
>
> v1 of the WebComponents standard has been agreed upon by all major vendors 
> and I'm optimistic about its availability (I believe we'll see it available 
> next year in the evergreens)
> Others don't share my optimism and there is also the issue of mandated IE 
> support. 
>
> I guess we'll see what will happen next year. 
>
> In the end, I would like to say that the situation is so foggy that I 
> don't really have a solid recommendation. 
> elm-mdl looks like a dead-end while webcomponents is so brand new that we 
> still haven't figured out how to use it. 
>
> The best way forward now might be to use the 0.18 port of elm-mdl with the 
> flat hierarchy recommendations from the reuse part of the guide. Choose not 
> to block. 
> This might allow for an easy refactoring to a better technology. 
> (webcomponents) 
>
>
>
>
>
>
>
> -- 
> 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] Re: What up with elm-mdl?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 21, 2016 at 7:02:15 PM UTC, Rex van der Spuy wrote:
>
> But there's there's a MichealCombs28 fork of elm-mdl for 0.18.
> Should I use that instead?
>

I'm using it until a new debois/elm-mdl becomes available. Seems to work 
just fine.

-- 
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 structure Elm with multiple models?

[David Legard]

One method which was suggested for Messages is that you define them all in 
a 'super-module' which is imported by Main and any other modules that need 
them

module Global  exposing (..)

type Msg = NoOp | Home | GoBack | ... | ...


...then...

module Main exposing (..)
import Global exposing (Msg)


.. and ..

module View exposing (..)
import Global exposing (Msg)

.. and so on


Maybe you can extend this approach to incorporating multiple models.

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