grapoza / vue-tree Goto Github PK

You can already do this by specifying modelDefaults on the tree.

The current npm package allows the user to use either the pre-built component or the SFC .vue directly. However, there is a better, standard way of doing this that will also allow the demos and documentation to be improved.

https://vuejs.org/v2/cookbook/packaging-sfc-for-npm.html

Need to have related events; radioselected? or just reuse checked?

Basically adds auto focusing to the new node when nodes are added, and to the parent or previous sibling when a node is removed

https://html.spec.whatwg.org/#dnd
https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API

ARIA drag-and-drop attributes are deprecated in ARIA 1.1 and will not be implemented.
https://www.w3.org/TR/wai-aria/#attrs_dragdrop
https://www.w3.org/wiki/PF/ARIA/BestPractices/DragDrop
https://dev.opera.com/articles/accessible-drag-and-drop/

as title

Pandoc may need:

• Custom CSS/HTML template; possibly a way to generate something like that? If not, we can always script it out.
  • https://pandoc.org/MANUAL.html#templates
  • https://github.com/jgm/pandoc-templates/blob/master/default.html5
• https://pandoc.org/demos.html
• Build docs as part of the build script (if it needs to be done in appveyor, see krlmlr/r-appveyor#82)
• Add YAML metadata file (https://pandoc.org/MANUAL.html#extension-yaml_metadata_block)

For Github:

• Add an output directory inside docs
• Add .nojekyll in the output directory
• Add output content to .gitignore, except for .nojekyll
• Add an npm task to build the docs
• Update sources to work with pandoc
• Add npm task usage to appveyor.yaml, and have it merge master into gh-pages on releases after docs build
  • https://gist.github.com/chrisjacob/833223#gistcomment-90988
  • Clone repo
  • Check out gh-pages branch
  • Copy output into <version> folder of gh-pages branch
  • Commit
• Possibly have a default index.html that auto-redirects to the latest version?

This should include:

• Proofread, clarify, and get feedback on the main documentation index
• Add a left nav to the docs to make it easier to find examples/demos
• Restructure the pandoc template used for the documentation
• If it makes sense, break down the main doc to separate pages
• Rework the CSS (something like Jest's docs for code samples)
• Expand the demos, and possibly unify the demos?

Adding a way to specify the value of the title attribute will help with accessibility.

The main issues with documentation are:

1. Local documentation builds link to the most recent published version of the component instead of the locally built version which (in most cases) you're trying to document
2. Docs built when a package is published also link to the most recent published version of the component instead of the published version that matches the documentation's version

My TypeScript-fu is woefully inadequate. Use this project to get more experience with TypeScript, and hopefully reap the benefits.

• Get the project configured with TypeScript
• Turn the existing enums contents into real enums
• Move the definition (and validation/normalization) of a NodeSpec into a type

https://vuejs.org/v2/guide/typescript.html
https://www.digitalocean.com/community/tutorials/vuejs-using-typescript-with-vue

When emitting treeViewNodeAdd, the TreeViewNode component passes this.childModel instead of just childModel, resulting in a null value always getting passed to the event in $_treeViewNode_onAddChild.

this.$emit('treeViewNodeAdd', this.childModel, this.model, event);

should be

this.$emit('treeViewNodeAdd', childModel, this.model, event);

https://www.w3.org/TR/wai-aria-practices/#TreeView
https://www.w3.org/TR/wai-aria-practices/#kbd_roving_tabindex
https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-2/treeview-2a.html (this one has good descriptions of each key's actions)

Might be worth watching this bug to see how they implement it, since it's the same problem this tree will run into with any input in a node:
vmware-archive/clarity#3573

Is your feature request related to a problem? Please describe.
Allowing the user to specify which property to use as the child nodes obviates the need to pre-format node data a certain very specific way.

Describe the solution you'd like
Pass in new prop. Handle it.

Describe alternatives you've considered
None.

Additional context
None.

Radio button group initialization (basically the selection of a single radio button from a group) is currently done through a hacky radioGroupValues property on the tree. Internally it's fine, but it's not a great UX for anyone who wants to initialize radio button group selection, and there's no external need for it beyond that since the tree exposes a getCheckedRadioButons method.

A new value should be accepted on the tree view spec for a node to indicate it should be initially selected. This will simplify the prop surface of the TreeView component, and hopefully make tree view radio button initialization more intuitive.

        if (!event.target.matches("input, .tree-view-node-self-expander, .tree-view-node-self-action")) {
          this.$emit('treeViewNodeClick', this.model, event);
        }

In IE, event.target does not have matches. Fix it.

• https://github.com/holiber/sl-vue-tree
• https://elbywan.github.io/bosket/vue/ (https://github.com/elbywan/bosket/tree/master/src/vue/components)
• https://github.com/scalia/vuejs-tree
• https://github.com/halower/vue-tree
• https://github.com/riophae/vue-treeselect
• https://www.telerik.com/kendo-vue-ui/components/treeview/
• https://ej2.syncfusion.com/vue/documentation/introduction/

Adding a prop to the treeview that lets a user specify default node values once for all nodes can cut down on the amount of model data creation the user needs to do to populate the treeview. For instance, in a treeview that is all enabled, collapsed, unchecked checkboxes the user could use a modelDefaults of

{
  expandable: true,
  selectable: true,
  input: {
    type: 'checkbox',
  },
  state: {
    expanded: false,
    selected: false,
    input: {
      value: false,
      disabled: false
    }
  }
}

Admittedly. some of this would be handled by the defaults in the treeview implementation itself. However, this would let a user make these explicit without repetition, as well as setting non-default values only once.

A single node model that specifies any of these values would override the defaults provided here.

Figure out what can be done with current styling, add extra if needed

Magic strings for the allowed selectionMode values (null, single, multiple, selectionFollowsFocus) are strewn through the code. These should be constant values somewhere.

https://vuejs.org/v2/style-guide/

Nodes can be searched using the getMatching method on the tree view, but it would be good to have a convenient way to filter the visibility of nodes. This would probably require:

• A way to set a node's visibility as part of the treeNodeSpec
• A method to go through the tree nodes (at the TreeView level) to set that visibility based on a provided method

Debouncing of the filtering would be outside the scope of the treeview and would be the responsibility of the caller.

In 1.x the treeview directly manipulates the data model handed in by the user. Clearly this isn't ideal.
The tree data can be made to wrap the user's data and maintain reactivity. Similar to the improvements made in 1.x, properties from the data used in the tree will be specified in the tree/node data.

Something like the following structure may work for a node:

{
  childrenProperty: 'tickets', // See description below
  idProperty: 'guid' , // See description below
  labelProperty: 'text', // See description below
  expandable: true,
  selectable: true,
  ...
  input: {
    type: 'checkbox',
    name: 'checkbox1'
  },
  state: {
    expanded: false,
    selected: false,
    input: {
      value: false,
      disabled: false
    }
  },
  data: { // THIS IS THE USER'S OBJECT
    text: 'Text and words',
    guid: '00000000-0000-0000-0000-00000000',
    tickets: [...],
    ...
  }
},

Each xyzProperty property's value is the name of the prop from data that contains a value to use in the tree. For instance, childrenProperty set to 'tickets' means this node's children are contained in the data.tickets (which must be an array).

The tree can have new props (something like xyzPropertyResolver) that takes a function used to resolve what the prop should be at the time a node's created handler is called if a xyzProperty is not specified for that node. Something like:

(data) => data.text ? 'text' : 'label'

If neither of these are specified, then a default value is used (e.g., 'children').

Very little configuration has been done, and a better job could be done to make the TreeView's default build outputs a bit better.

This basic document should lay out a reasonable blueprint for anyone wishing to contribute to the project, with the expectation that it will be a living document.

Is your feature request related to a problem? Please describe.
Allowing the user to specify which properties to use as the label and ID obviates the need to pre-format node data a certain very specific way.

Describe the solution you'd like
Pass in new props. Handle them.

Describe alternatives you've considered
None.

Additional context
None.

Icons? titles?

When the treeview is mounted, the watcher for the tree view node's model.treeNodeSpec.focusable fires. This handler actually causes the node to gain focus immediately, which is not what we want when the mount logic is initializing the tree's focused node.