Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialise all node attributes on node creation #710

Closed
wwqrd opened this issue Oct 10, 2018 · 3 comments
Closed

Initialise all node attributes on node creation #710

wwqrd opened this issue Oct 10, 2018 · 3 comments
Assignees
Milestone

Comments

@wwqrd
Copy link
Contributor

wwqrd commented Oct 10, 2018

Context: Sociogram highlight props should actually toggle true/false, they’re currently added and removed. If we changed that to flip the value, at which point should the attribute have been added?

It was decided that actually nodes shouldn't have any missing attributes, and that they should all be initialised on node creation with blank values as follows:

Boolean: false
Everything else: null

If any attributes are provided when the node is created, these attributes should be set with the provided values.

Related: https://github.com/codaco/Architect/issues/253

@jthrilly
Copy link
Member

If any attributes are provided when the node is created, these attributes should be set with the provided values.

Just for clarity: this means any values from the node form will override these default values.

@bryfox
Copy link
Contributor

bryfox commented Oct 10, 2018

I assume this issue also covers "Sociogram highlight props should actually toggle true/false".

Presently, allowHighlighting defaults to true in NC and Architect does not explicitly set false (at least initially). One of these two should change; I can file a separate issue, but I'm not sure which is preferable.

I'd assume that the mere presence of highlighting is sufficient and we wouldn't need allowHighlighting, though maybe it's to preserve state in Architect when editing? If so, then defaulting to true makes sense to me... thinking of this from the point of view of authoring a JSON protocol.

@bryfox
Copy link
Contributor

bryfox commented Oct 10, 2018

If the intent is to require everything in the network to have props, then I assume external data should also be updated when added. I also assume we'll add only the attributes relevant to the type of data. For forms, this is straightforward. For external data, would we use the prompt/node subject? Or would we favor the type property if it exists like we do for labels?

In either case, externalData.type probably needs to be better-documented. If we don't use type here but do for labels, that seems confusing. If we do use type here, then we probably need to ensure the type exists in the registry, and define behavior if it doesn't.

@jthrilly jthrilly added the NC label Oct 15, 2018
@jthrilly jthrilly removed this from the M8 - Lochs and Glens milestone Oct 22, 2018
@jthrilly jthrilly added this to the December milestone Dec 17, 2018
@jthrilly jthrilly self-assigned this Dec 17, 2018
@jthrilly jthrilly modified the milestones: December, January Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants