Wait... ```json ["content", "Apps"], ["k", "32267"], ``` Do they know that JSON arrays are not position-guaranteed across parsers? xD Uh oh. I am also not a fan of profile lists in the tag itself. That can easily become stupidly bloated - event size is not exactly unimportant - for storing, parsing and indexing. Would rather see a "root of truth" event with references (p, e) to more details; we already have a list kind, use that for profiles. And there are application-specific storage events, those can be used for "configuration". Just squishing everything into one event leads to unneccessary complexity and loss of type-safety. ```go type Event struct { Id string Kind int } type Community struct { Name string Owner Pubkey // ... } func NewCommunityFromEvent(Event e) (Community, error) ``` This approach is cleaner, allows the constructor to go fetch adjacent events, and properly return an error if there is one. In doing so ("root of source"), you also allow reusability of components. Don't overstuff one event. If you want this approach, please look at Matrix and it's m.room event type, and then go to m.device next. You will understand what I mean. x) View article →

Replies (5)

No, actually. Go stdlib's json parser is, V8 probably is, JSC very likely, but many other engines and parsers are not. For example, I have no idea if C#, Flutter or Swift adhere to that behaviour or not - it is largely dependent on what "backend" they use to store arrays. Some may use an ordered list, some may also just... don't. Whilst _probably_ most engines and parsers do respect array element ordering, I would highly advise to never take that for granted at all. x)
I did a quick test on Go: ``` PS C:\Users\ingwi\Work\jsontest> go run .\main.go key 1 value 1 key 2 value 2 PS C:\Users\ingwi\Work\jsontest> type main.go package main import "encoding/json" type Data struct { Array [][]string } func main() { jsonstr := `{"array":[ ["key 1", "value 1"], ["key 2", "value 2"] ]}` data := Data{} err := json.Unmarshal([]byte(jsonstr), &data) if err != nil { panic(err) } for _, item := range data.Array { key := item[0] value := item[1] println(key, value) } } ``` So that one absolutely respects it. But am in a bit of a hurry, so I can't really validate the others. If you have like an OpenClaw or something, perhaps let them run some tests to see which places do and which do not keep array order. :)
I could have sworn that some implementations of JSON parsers do not do that due to their backing array implementation. But, at least according to ECMA-404 (epic name btw xD) that is actually part of the spec. Well, I am officially wrong and stand corrected. x)