Confused about state keyword

[bobhy]

I get the idea of having private state in the component, but the sample article confused me.

1. If state is a keyword, why does it need a : in the example?
2. How would I declare 2 records as private in a component?
3. Why not make the keyword private?

[gdotdesign]

Yeah, so this is something I have struggled with:

• we need a way to differentiate a component with internal state from ones that don't, this is why there is the state keyword
• the type of the state must be defined somewhere
• the initial state must be defined somewhere
• there should be only one place for all of this

so this was the syntax I came up with.

I agree that the colon : is not necessary, and in retrospect the state here should have been initial-state but having a two world keyword seems off.

I'm open to suggestions on how to make this more clear.

[bobhy]

I'm a total n00b on this framework, I'm trying to learn what's going on by studying the test cases. So my advice is offered only with extreme caution and should be taken the same way.

First, I'm confused by basic declarations, Why is it blah: String ... but record blah {...}?
It seems some things are declared by keyword: component, record, fun, while others (basic types?) by : <type>, fields of a record and properties.

I think of property and state: as a kind of modifier. So property Foo: String makes sense. How do I declare a property that's a record? Would it be property Foo: record Bar? I can't find a sample in tests, so maybe this is just not supported, but if it were, I would guess that it should be property Foo: Bar (but no record keyword).

I'm sorry, I cannot come up with a small fix, I want to change everything! Being an old C programmer, I'd propose to use the leading keyword style everywhere. record Foo and component C1 are already like this, but basic types would become::

record Foo {
    String name = 'abc', 
    Number cost = 22.33
}

The name of a record would become a declaration keyword too:

record Bar {
    Foo item_1 = {name = 'item1', cost=22},
    String comment = '...'
}

and then both properties and internal state would be:

component C1 {
    property Foo argle
    property String bargle = 'gargle'
    state Foo working_storage = {...}

   ...    
}

As another way of digging in, I've started fixing typos and grammar in the guide and will be pushing those in a bit. Should I push them from my own repo or may I create a branch in your existing repo?

[d3dc]

Maybe use english like stores' connect Store exposing { ... }?

state storing State initially {
  ...
}

it seems like there's gonna be a lot of single-use records created for this, why not just create the record type?

state initially {
  ...
}

I think = is idiomatic for "initially" really, but then it looks like a variable.

I also imagine this scenario:

state storing Book initially Book.empty()

[kingsleyh]

I quite like the state initially {} since I had to create a lot of single use Records just for local state - since the record currently has to be created outside of a Component - there is I suppose potential re-use of the Record - but this seems unlikely and so far I have found no opportunity for that.

[gdotdesign]

After reading the comments there seems to be some confusion how state in a component works.

Basically it works the same as in React:

• there is only one state (which is a record)
• it's modified using the next keyword (this.setState)
• in a component the state can be referenced using the state variable (this.state)

The current state : Type { initialState } syntax was ment to convey that the state object of the component has the record type of Type and the given initial state.

I think what I learned here is:

• it was a mistake to use the state keyword to multiple places (state definition and reference)
• having it as a component entity which mislead people to believe there can be many states
• the colon : was not necessary

I still don't know how to convey it in a nice and clean way.

I like the state Type initially { initalState }, maybe it's expressive enough.

[bobhy]

As a newcomer, I'm looking for analogies and minimum number of concepts. I came in thinking of state as a kind of local-only property because that's the only example I see of a data item being declared and defaulted within in a component. Does the name of the variable have to be state? (implying you cannot have a property called state...) If it did not, you could have something like local myState: Type {initial} ( or private) and it would feel natural. And the canonic declaration could be local state: Type {initial} which I think would look natural to more experienced eyes.

I do have a problem with initially, though. That makes initializing state different from any other value in the language, and why should it need to be?

This has got to be my last post on this thread till I gain more experience with Mint to support my blather. Thanks for your patience!

[d3dc]

@bobhy I might not be helping too much, but have you taken a look at React's setState before?

State is a separate immutable object from your component and there are specifics as to how it will update.

I do think it could be interesting to define properties on the state object with the state keyword working like a visibility keyword (public/private). But that will make it very hard to do e.g. state initially Book.empty()

[gdotdesign]

After thinking about this for a while I've decided to make the state keyword similar to property.

The new version will look like this:

• state will behave like property: it will have an identifier a type and a default value, it's accessible in the same scope
• next only updates the specific state properties but it does not have to include all of them
  For example if a store / component has two state properties a and b then a next can be either next { a = value } or { b = value } or { a = value, b = value }
• stores will use state as well to be in line with the local state of a component
• state updates with next is typed checked as usual

I've created a gist from the counter and drag example using this approach: https://gist.github.com/gdotdesign/fcbbc1877f92295b76ec5d9acb88e958

This means that:

• state variable is removed from both components and stores
• state does not need a separate record type
• It's more easy to understand because of the similarities to property

I'll do the implementation and see how it works.

I would appreciate any feedback on this, especially on the keyword: does state and next conveys the idea behind them? would any other keyword be better?

[kingsleyh]

I think this sounds like an awesome idea. More consistent and easier to use. It also makes sense for stores since you don't pass a property into a store in the same way you do with a component. So using state instead here seems great to me.