Example usage of laziness:
We have an expensive layout algorithm which depends both on the data being laid
out and the view size. Whenever either of these changes, we need to re-run the
layout algorithm but we would prefer to do the computation only when absolutely
necessary and only once for a
; On Nov 27, 2017, at 2:37 AM, 'Rupert Smith' via Elm Discuss
> wrote:
>
>
>> On Monday, November 27, 2017 at 7:50:01 AM UTC, Mark Hamburg wrote:
>> P.S. Cyclic structures can be avoided by having the compiler perform a
>> strongly connected component
My bad. Cyclic generator not decoder. Recursive decoders have the same issues.
Mark
> On Nov 27, 2017, at 8:45 AM, 'Rupert Smith' via Elm Discuss
> wrote:
>
>> On Monday, November 27, 2017 at 4:33:57 PM UTC, Mark Hamburg wrote:
>> That page already has an examp
If you have a recursive JSON structure to decode, then the decoder either
needs to refer to itself (a cycle) or it needs to generate a new decoder on
each recursive step.
Mark
On Thu, Nov 30, 2017 at 2:43 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:
>
> On Thursday,
Functions are also heap allocated objects and reference other objects — e.g.,
decoders — just like other objects do.
Mark
> On Dec 7, 2017, at 2:32 AM, 'Rupert Smith' via Elm Discuss
> wrote:
>
>> On Tuesday, December 5, 2017 at 5:16:22 PM UTC, Mark Hamburg wrote:
&
would be.
Mark
> On Dec 8, 2017, at 1:55 AM, 'Rupert Smith' via Elm Discuss
> wrote:
>
>> On Friday, December 8, 2017 at 5:55:36 AM UTC, Mark Hamburg wrote:
>> Functions are also heap allocated objects and reference other objects —
>> e.g., decoders —
scope.
Mark
> On Dec 8, 2017, at 6:13 PM, Mark Hamburg wrote:
>
> Functions get garbage collected. Otherwise think what would happen every time
> you use partial function application or define a function within a let or
> other nested context. Because those functions (can) capt
t; wrote:
>
>
>> On Saturday, December 9, 2017 at 2:13:18 AM UTC, Mark Hamburg wrote:
>> Functions get garbage collected. Otherwise think what would happen every
>> time you use partial function application or define a function within a let
>> or other nested contex
Should reference equality be a thing in a pure functional language? At
least beyond a point where certain optimizations may or may not apply? So,
for example, Html.Lazy uses reference equality as a fast way to
short-circuit re-running a view function (and comparing the resulting tree)
and that
I'm hoping that's not how it is expected to work because it means that a view
layout decision — we need to put the remove button in with the counter display
and buttons — now spreads to the messages and update function. I much prefer
the solution that someone else posted where viewWithRemove tak
Or more succinctly, the issue to be dealt with in the counter with remove
button case is that the view needs to be able to "send" more messages not that
the counter update function needs to handle more messages.
Mark
> On May 18, 2016, at 1:40 PM, Mark Hamburg wrote:
>
>
Some members of my team just raised the concern that not providing for item
identity could cause focused text fields to lose focus and a bunch of edit
state. I said I would pass it on.
> On May 18, 2016, at 9:24 AM, debois wrote:
>
> I was using virtualdom key for two things, both of which I c
Elm also doesn't have generalized union types even with tags. For example,
one can't have a universal NoOp message type that can be included in other
message type definitions and recognized and generated from generic code.
Mark
On Friday, May 20, 2016 at 11:46:49 AM UTC-7, Joey Eremondi wrote:
Whenever you accessed the list, you would get an element of type A | B. To use
if further, you would need to type case it, pass it to something that wanted A|
B or A | B | C etc, or put it through some sort of type cast operator that
could give you a Maybe A or a Maybe B. Elm, of course, doesn't
I was talking with coworkers about my team's experiments with Elm and I found
myself having to blunt their interest because of the current state of Elm 0.17
— documentation still has holes, tutorials haven't had a chance to arise, some
functionality is still missing relative to 0.16, etc. This w
would just jump headlong into 0.17 and enjoy it.
>
> - Rex
>
>> On Tuesday, May 24, 2016 at 12:26:31 PM UTC-4, Mark Hamburg wrote:
>> I was talking with coworkers about my team's experiments with Elm and I
>> found myself having to blunt their interest because of
On May 27, 2016, at 3:24 AM, Alexey Shamrin wrote:
>
>
>> So, while I'm mostly interested in seeing 0.17 get fleshed out, I think
>> having a link on the front page of elm-lang.org that would take one back to
>> the 0.16 world would be a good thing while 0.17 matures.
>
> By the way, Elm 0.16
I've started experimenting with a general pattern of having update functions
return:
* Maybe a new model (to make it easier to not generate new models on no-op
cases and hence work better with lazy rendering)
* A list of commands. These can be batched up into a single command at the top
but in
That discussion seemed to just peter out. I've wanted a write equivalent to
.field since I find myself writing (\v m -> { m l field = v }) a lot. On the
other hand, I'm also wary because I see a lot of beginning Elm code from myself
and others on my team wander toward an imperative style that do
Easy to say but less easy to implement if one wants to keep pieces isolated
from each other.
Considering the 0.16 counter example, we have an extended view type that can
trigger not only counter messages that can be handled by the update function
for counter models, it can also generate remove
For the parent/child communication problem, the approach of returning a triple
has felt the best to me as well of the choices I've seen.
I note, however, that this is different from the old list of counters case
where we needed to signal remove from the view cluster for the counter. In the
gene
gt;> about here?
>>
>>> On Wednesday, May 18, 2016 at 4:40:07 PM UTC-4, Mark Hamburg wrote:
>>> I'm hoping that's not how it is expected to work because it means that a
>>> view layout decision — we need to put the remove button in with the counter
&g
On Jun 17, 2016, at 4:58 PM, Joey Eremondi wrote:
>
> Elm 0.17 is just a month old. It will, unfortunately, take time for all the
> resources to update.
This was why I felt Elm adoption would benefit from keeping Elm 0.16 more
visible perhaps with messaging along the lines of the following:
T
Interesting. I've felt some tension around this as well. I've got an app with a
grid of photos that needs to run layout logic based on the width available.
Right now, I'm basically deriving that width from the window width but that
splits my page layout between Elm and CSS as processed by the br
On Jun 28, 2016, at 6:12 AM, Wouter In t Velt wrote:
>
> My specific use case: I have a list of children with a number of internal
> messages (e.g. updates on each child). One of the functions I need to
> implement is 'RemoveMeFromList', which is a button on each child. This
> message type can
I would absolutely tag the tasks. You can do this in the response action. I
recommend keeping a counter in the model and advancing it whenever the basis
for requests changes.
Aborting would be ideal but it's harder or potentially impossible at present.
Mark
--
You received this message becaus
In my app, I changed the standard update signature from:
msg -> model -> ( model, Cmd msg )
to:
msg -> model -> ( Maybe model, List msg, List notification )
Here was the reasoning for each of the changes:
1. Returning Maybe model: Laziness in view generation depends on not needlessly
changing
t; some use cases.
>
>> On Tuesday, June 28, 2016, Mark Hamburg wrote:
>> I would absolutely tag the tasks. You can do this in the response action. I
>> recommend keeping a counter in the model and advancing it whenever the basis
>> for requests changes.
>>
>&
This was touched on in a related way in this thread:
https://groups.google.com/d/msg/elm-discuss/0XbEEb4hkjM/dy6Q3XHIBgAJ
and is also related to some of the recent discussion of aliases to aliases,
but neither of those touch quite as directly on this issue/request.
In reviewing the Elm code my t
The first option feels repugnant from an encapsulation standpoint. I've built
the second option and it works but it increases the amount of boilerplate in
hierarchical systems because we now have three results to deal with in update
functions. That's lead me to think about but not yet write a co
I will say that one thing that feels odd about the top-level request manager
approach is that it uses containment as the way to hook things up. That works
fine with one piece filling that role but would get messier with two. But with
signals gone, containment is the primary thing we have left.
Here is the general flow with the request system:
Instead of returning Cmd msg as part of the update result, modules return Req
msg (or List (Req msg) if you don't want to build Req.batch). These get mapped
and bubble up just like commands. When they get to the API handler level,
however, they
We're still awaiting an official answer from Evan. In the meantime, the best
answer I've seen from the standpoint of not contaminating the counter messages
and update function with something that they don't care about is to put the
complexity in the view function which is, I would argue, where i
entMsg? In reality, my components
> are more separated in depth, by four levels. Bit ugly, but seems it's all we
> have right now. It actually appears elegant in contrast to my approach.
>
> 2016-07-07 21:18 GMT+02:00 Mark Hamburg :
>> We're still awaiting an official
My strategy for this sort of thing is to only send the new request when the old
(stale) request returns. That works fine without signals.
Mark
> On Jul 8, 2016, at 6:19 AM, Charlie Koster wrote:
>
> Now that signals are gone I'm not quite sure how I would debounce inputs. The
> typical exampl
On Jul 7, 2016, at 6:22 PM, Alex Lew wrote:
>
> I wrote about a generalization of that pattern a week or so ago, in case
> you're interested:
> https://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98
I like this approach. It emphasizes
een the model hierarchy and the view hierarchy and weakening
the notion that there is a one-to-one correspondence all the way down.
Mark
On Sat, Jul 9, 2016 at 2:27 PM, Mark Hamburg wrote:
> On Jul 7, 2016, at 6:22 PM, Alex Lew wrote:
> >
> > I wrote about a generalization of tha
This is the issue that drove me to stop using the equality operator in any
"generic" code.
It would be nice if the compiler would catch this.
I would argue for using instantiation equality as a fallback but that would
eliminate various opportunities for compiler optimization.
Mark
> On Jul 9,
Elm already has some built-in typeclass like concepts — e.g., comparable — so
tracking equatable as a required property wouldn't seem like an entirely new
notion. On the other hand, generating useful error messages would require being
able to report the path through the logic that leads to where
make that case
right now for Elm and that's frustrating because I would like Elm to be a
viable answer.
Mark
> On Jul 10, 2016, at 11:17 AM, Mark Hamburg wrote:
>
> Elm already has some built-in typeclass like concepts — e.g., comparable — so
> tracking equatable as a
On Jul 10, 2016, at 12:40 PM, Mark Hamburg wrote:
>
> This also points to a bigger issue with Elm not living up to its "no runtime
> exceptions" hype.
Not just hype. Hype would be people giving talks about and talking about how
wonderful it was to be freed of runtime except
To the extent that our work is in production, it's been in production that
we've been bitten by this because most of the time something else leads to a
recognition that the composite structures are unequal before we get around to
testing equality for functions within those composites.
Mark
> O
A pessimistic definition would seem to be:
* A value with function type is non-equatable
* A tuple, tagged value, union, or record containing a non-equatable value is
non-equatable
* A type parameterized by a non-equatable type is non-equatable
In other words, non-equatableness spreads pessimist
On Jul 11, 2016, at 4:23 PM, Mark Hamburg wrote:
>
> A bigger problem is that the requirement that something be equatable or the
> property that a type is not equatable becomes a hidden part of the interface.
So, here is a more harsh suggestion: if a type can't be locally pro
On Jul 11, 2016, at 4:58 PM, Christopher Anand [g]
wrote:
>
>
>> On Jul 11, 2016, at 7:28 PM, Mark Hamburg wrote:
>>
>> On Jul 11, 2016, at 4:23 PM, Mark Hamburg wrote:
>>>
>>> A bigger problem is that the requirement that something be equatab
I think I'm going to revise my stance on how this issue should be handled. I am
now gong to argue that function equality should be handled via object identity
— i.e., two closures constructed at different times are necessarily unequal.
What this breaks is referential transparency and more specif
Here is the case I'm looking at: My SPA can be in one of three state —
probably more before I'm done but three will be sufficient for this
discussion — logging in, active, and logged out. So, here's my model:
type Model
= LoggingIn LoggingIn.Model
| Active Active.Model
| LoggedOut LoggedOu
you should use the returned user ID to switch to some
> new state.
>
>> On Tuesday, 9 August 2016 10:12:26 UTC+10, Mark Hamburg wrote:
>> Here is the case I'm looking at: My SPA can be in one of three state —
>> probably more before I'm done but three will be suff
How big do the case statements in your update functions get? Or are your pages
just not that complex?
I tend to like to keep modules in any language to a size that can be reasonably
read and comprehended. That doesn't always happen. I've written some behemoths.
But I tend to feel guilty when do
I get where you are coming from in saying that the update function becomes
essentially fifty smaller functions. Some of the questions on modularity
then stem from whether you ever expect someone to read through and consider
an entire Elm module or whether you expect that people will make changes
On Aug 17, 2016, at 4:25 AM, Oliver Searle-Barnes wrote:
>
> e.g. I'm using websockets to communicate with the server, in my previous
> experience I would have implemented a Store of some sort which took care of
> communication with the server and allowed the view layer to just worry about
> a
Very nice but perhaps better named "orElse".
Mark
> On Aug 21, 2016, at 5:49 AM, slosh.wo...@gmail.com wrote:
>
> I'm working on a program that attempts to parse a String in several different
> ways, and uses the first one that matches. Each parse function returns a
> Result. At first I had ne
This suggests a generalization to the Elm update/view architecture pattern.
The functions stay the same but the signatures change:
module Component exposing (InternalState, ExternalState, InternalMsg, init,
update, view)
type InternalState = ... -- the purely internal information for the
compo
Richard's definition of large application (36,000 lines) and my definition
(Photoshop, Lightroom, ...) are rather different in scale, so maybe that's
part of the difference in perspective and my sense that one needs to find
good ways to carve things apart.
With that in mind, let me put an examp
On Aug 25, 2016, at 2:51 PM, Richard Feldman
wrote:
>> Richard's definition of large application (36,000 lines) and my definition
>> (Photoshop, Lightroom, ...) are rather different in scale
>
> OP said "If i have a site with lots of features what is the best way to
> orgainze everything?" an
t? ;-P am winking so hard right now>
>
> On Thu, Aug 25, 2016 at 4:52 PM, Mark Hamburg
> wrote:
>
>> On Aug 25, 2016, at 2:51 PM, Richard Feldman
>> wrote:
>>
>> Richard's definition of large application (36,000 lines) and my
>>> definition (Pho
I'm going to try to take the large app design questions and focus them on a
more narrow and admittedly contrived example.
Say the people doing the client coding needed to be able to take a URL
string and fetch a string via HTTP. (Yes, this is covered in the HTTL
module. Bear with me. I'm trying to
case newModel.pendingFetches of
> head :: tail ->
> ( { newModel | pendingFetches = tail }, head )
>
> [] ->
> ( newModel, Cmd.none )
>
>> On Thu, Aug 25, 2016 at 5:51 PM, Mark Hamburg wrote:
>> I'm going to try to take the lar
e model
> in
> case newModel.pendingFetches of
> head :: tail ->
> ( { newModel | pendingFetches = tail }, head )
>
> [] ->
> ( { newModel | waitingForResponse = False }, Cmd.none )
>
> On Thu, Aug 25, 2016 at 9:39 PM, Mark Hamburg
>
I've been determined to try to use Elm as a solution for building
potentially large applications. Maybe I should just be taking what you are
saying as an indication that it's not useful for that and I should go back
to looking at JavaScript. I'd hate to do that because I like the typed,
pure functi
ard for dismissing your problem, so I
> don't really know where to go from here.
>
> On Fri, Aug 26, 2016 at 11:14 AM, Mark Hamburg
> wrote:
>
>> As I said, I know how to write the queue if that's what I really want.
>>
>> My problem is that when a mo
I've already hit the problems.
I'm trying to rebuild the successor to some past systems in Elm and one
thing we learned on those systems was that to get good performance it was
critical that we prioritize HTTP fetches so that we didn't ask for the low
priority items at the same time as the high pr
;t need Cmd.map since commands
would only exist at the top level of any application, so the Elm
architecture seems to be built with an expectation of nesting.
Mark
On Fri, Aug 26, 2016 at 11:52 AM, Josh Adams wrote:
> On Friday, August 26, 2016 at 1:24:15 PM UTC-5, Mark Hamburg wrote:
>&
Thanks, Richard. That all works if everything is essentially sitting
together at the top level and talk to the model. As I said, writing the
queue isn't really the hard part. I know you just like to let stuff
accumulate in one monolithic piece, but if you wanted to subdivide some of
the major secti
Oops. Typo. That should be
| Queued Int (Cmd msg)
On Fri, Aug 26, 2016 at 3:03 PM, Mark Hamburg wrote:
> Thanks, Richard. That all works if everything is essentially sitting
> together at the top level and talk to the model. As I said, writing the
> queue isn't really the har
On Aug 26, 2016, at 3:34 PM, Richard Feldman
wrote:
>
> AppCommand seems like overkill. We need to prioritize our HTTP requests. Do
> we really need a drop-in replacement an entire foundational core library to
> do that? Why not just say "we have a business need to do HTTP requests in a
> cer
I'm working on some example code. I'm varying between a moderately fleshed
out example of the plumbing but with little backing it up and a fully
worked but trivial to the point of not being interesting example. The
general model, however, works as follows:
• We have a service model and a client mo
Not using Cmd does make (!) far less useful.
Mark
On Sat, Aug 27, 2016 at 3:14 PM, Mark Hamburg wrote:
> I'm working on some example code. I'm varying between a moderately fleshed
> out example of the plumbing but with little backing it up and a fully
> worked but trivial
I think the problem is that "components" in other communities tends to mean
"reusable components" and while reuse is certainly valuable, what is of more
concern is how to subdivide and partition state/logic/functionality etc and how
to do so in a sufficiently general pattern that people don't ne
One thing that might help in a Thinking in Elm context would be to put more
emphasis on hierarchical model construction and hierarchical view construction
as separate ideas. The latter is mostly about breaking things down via
functions. The former is about defining data types and functions on th
The SPA we're building is likely to factor out as:
Top level
UI Shell
Shared sidebar
Page 1
Page 2
Etc
Service provider
The UI shell manages the overall UI state — e.g., which page is active — and
structure. The service provider maps the API
ily domain related,
> but requires a task/command - e.g. generate a random number? Are these
> types of situations factored into your design?
>
>
>
>
> On Saturday, August 27, 2016 at 6:14:41 PM UTC-4, Mark Hamburg wrote:
>
>> I'm working on some example code. I&#
The Elm equivalent if it existed would probably be:
.name= : String -> Person -> Person
I have certainly written plenty of code where I would have appreciated this
but I do also worry that treating the fields in a record like this tends to
encourage imperative thinking and discourage thinking ab
ok like:
(model, Batchable.none)
:> firstUpdate
:> secondUpdate
This would make the generalization of the Elm architecture that keeps the
"command pattern" but doesn't use the "Cmd type" fit in perfectly well with
the simpler Cmd patterns.
Mark
On Sun, Aug 28, 2016 at
2016 at 9:55 PM, Mark Hamburg wrote:
> I have started thinking about whether there would be a useful refactoring
> of Cmd and Sub to support some shared structure that could also work with
> the sort of emulations that I've been building. It's not that the
> emulations are har
well studied
> in Haskell, and give way to things like Lenses. So having these isn't
> frowned upon in the functional community in general.
>
> On Sun, Aug 28, 2016 at 9:46 PM, Mark Hamburg
> wrote:
>
>> The Elm equivalent if it existed would probably be:
>>
>&
Caveat that can mess with the models in these cases: The index in the list
seems like it could be a risky choice for counter identifier. As long as we're
only adding counters, we're fine, but the moment we allow for deleting
counters, we risk getting a delete followed by an increment without an
On Aug 30, 2016, at 12:42 AM, Peter Damoc wrote:
>
> There is an old Zen saying:
> Flat is better than nested.
>
> This means that if you have a choice, prefer the flat one. It doesn't mean
> that everything should be flat but that flat should be preferred.
Nested may, however, be more amen
me additional complexity (task
> queue, websockets,etc), but I haven't actually seen anything that would
> cause me to abandon the built-in command/subscriptions system. What if you
> need to do something in the page that is not necessarily domain related,
> but requires a task/command -
Html.none would produce a virtual DOM node but that node would not produce
anything in the actual DOM. It's usage is an alternative to list concatenation
and empty divs. For example:
div []
[ headerView model,
, model.error |> Maybe.map errorBoxView |> Maybe.withDefault Html.none
, b
e
> update : Msg -> Model -> (Model, ClientCommand)
>
> This adds some additional layers of abstraction at the top of the app where
> everything is wired together, but aside from that, this isn't so bad.
>
>
>> On Wednesday, August 31, 2016 at 4:32:13 PM UTC-
Over on Elm dev, there's been a debate over how to handle private state for
views that also have public state. Evan's sortable table and his recent
updates to the guide with respect to reuse have emphasized how to avoid
building much state into a model but that's left a gap for the cases where
priv
of some views have public data (which should be fed
> to it by the user) and some private data (which is for internal bookkeeping
> purposes only, like view states, a ripple or an accordion or so forth) and
> how to manage them in a useful way.
>
>
>> On Friday, September
function:
\x m -> { m | field = x }
And if I were in a language like Lua or JavaScript, I would probably create
a function to take a field name and give me back a getter/setter pair.
On Fri, Sep 9, 2016 at 2:02 PM, Mark Hamburg wrote:
> The most general/worst case has some per view p
elm-mdl is loaded with private state support in order to support various
Material Design Language elements. I'll let those who built it go into those
details. I was responding to the argument that the elaborate apparatus that
elm-mdl uses is "not the right way to do this in Elm" but those argume
> On Sep 10, 2016, at 1:22 AM, Peter Damoc wrote:
>
> Charlie was right, an accordion is a better example.
I'm sure it is. As is a date picker. As with lists of counters as models in the
Elm Architecture documents, my example is entirely contrived — hence, my
subject line — with the intent th
On Sep 10, 2016, at 10:05 AM, Josh Adams wrote:
>
> Would you be willing to paste some example code so we can see the problem you
> faced and the way you solved it? If so, maybe we could find that if you'd
> made one small tweak to your solution then you never would have achieved this
> level
On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes wrote:
>
> Mark, have you considered the approach that Evan took with elm-autocomplete?
> Personally, I found this a satisfactory approach to the problem of private
> state/events, I'd be interested to hear your take on it.
I watched the video
, it's really easy to end up linked to
the wrong private state and to the extent that one uses the same type of
view more than once, the type system won't catch this.
Mark
On Sat, Sep 10, 2016 at 12:43 PM, Mark Hamburg
wrote:
> On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes
>
those modifications, I need to
> make sure I hit everything. Otherwise, it's really easy to end up linked to
> the wrong private state and to the extent that one uses the same type of
> view more than once, the type system won't catch this.
>
> Mark
>
>
> On Sat, Se
On Sep 10, 2016, at 2:06 PM, Josh Adams wrote:
>
> As far as generalizability goes, I have overdone generalizing enough in my
> life that I try to justnot. When I see some things that are doing the
> same thing I'll extract function. If a bunch of functions work on the same
> sort of thi
There are things you can do in your code to help and things that Elm could
do (maybe already does) in its implementation to help:
For the data construction issue, you need to create an intervening function
that does the construction:
view model = lazy someViewHelper model.data
someViewHelper data
(Sparked by the great lightning talk at elm-conf on elm-style-animation)
A less contrived example of private state might be something built around
elm-style-animation. The animation is potentially simply part of the view
rather than the data model. We can again store that state separately but it
On Sep 19, 2016, at 7:28 AM, Noah Hall wrote:
>
> I would agree though,
> that if you are intended to rely on the existing JS/CSS libraries out
> there, you are probably better off investing time in making Elm part
> of your site, not making Elm your whole site. You will spend too much
> time lik
Web components may be a reasonable answer with the following caveats:
1. Getting these to work well for stateful components presumably relies on
the virtual DOM code playing nice with DOM node lifetimes. The new version
of keyed support in 0.18 may make this somewhat more difficult since it
then r
When writing a view function (or helper function that generates part of the
view hierarchy), is it better to take a function mapping values or messages
to parent messages or to use Html.App.map for this? In other words, is it
better to write:
viewCheckbox SetMyCheckboxState "My Checkbox" model.myC
k identity",
>> which seems a little silly.
>>
>> That's just my preference though. I think either one seems fine, as long as
>> you're consistent :-)
>>
>>> On Wed, Sep 21, 2016 at 10:19 AM, Mark Hamburg wrote:
>>> When writing a
So, could this thread be summarized as recommending two essentially independent
projects for "components" in Elm:
1. Make sure the virtual DOM works "sensibly" with elements with hidden local
state.
2. Provide a standard approach to building new web components using Elm.
Those two things would
The issue is that when you have external state, there need to be ways —
features, patterns of coding, etc — that prevent accidental destruction of
one component accompanied by creation of a new component when what one
wanted was an update to the existing component. This depends on having a
notion o
> insufficient about Keyed as a solution?
>
> On Thu, Sep 22, 2016 at 9:11 PM Mark Hamburg > wrote:
>
>> The issue is that when you have external state, there need to be ways —
>> features, patterns of coding, etc — that prevent accidental destruction of
>> one comp
1 - 100 of 255 matches
Mail list logo
