Open zverev opened 7 years ago
I suggest - keep in mind that "Event" is some kind of linked data. Objects may be linked in one event or may be represented separately
@zverev , @Godnik , I'd suggest to align naming according to our glossary, i.e. event(s) -> incident(s)
.
Also, if we name a field like <something>Id
(e.g. categoryId
), value type implies Number
(id's are usually numbers or GUIDs overall). I personally prefer more semantical naming (keeping meaningful category names as values - just like in proposed example), but that means switching from categoryId
to categoryName: "fires"
or even simpler: category: "fires"
.
The other aspect is nesting: why properties
? :) Basically, I'd keep geometry
nested but move all those values (id
, title
etc.) one level up.
Actually, I suggest some sort of basic normalisation (using normalizr or not - doesn't really matter at this moment). What I mean: to maintain an explicit relation between generic categories
and corresponding items
+ segregating loading/error statuses from actual data, e.g.:
{
loading: false, // <Boolean>
transportStatus: null, // <String> or <Object> representing XHR "error.message" or entire "error"
currentCategory: 'fires', // alternatively - "currentCategoryId" as <Number>
categories: [
{
id: 0, // <- still a question if needed
name: 'fires',
title: 'Fires',
description: 'News about wildfires'
},
...
],
incidents: [
{
category: 'fires', // used for internal mapping, could also be simply "categoryId"
id: 1,
title: 'Enormous wildfire raging in Chita city',
description: 'some huge amount of text representing that very fire'
detectedAt: '2015-03-10T09:30:37.386Z'
geometry: {
type: 'Point',
coordinates: [125.6, 10.1]
}
},
...
]
}
I suggest the following scheme:
I'm not completely sure about how to call map objects. Each of them represent some kind of event, so we may call them
events
. This also applies to API endpoints (I used the termitems
there). Also we may simply call them objects.