Fixes to address unintended props reshuffling behaviour

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.

[rpkyle]

Proposed changes introduced by this PR:

• The ordering of props in Dash components is maintained by providing object_pairs_hook=OrderedDict to json.loads .
• Handling of prop_keys exclusions has been refactored to account for removal of events, and to properly omit wildcards.
• R components now require children to be passed as a list or function, as in Dash for Python, and ellipsis is used for wildcards only, as the final formal argument for component functions.
• Component library dependencies are now copied to inst/deps rather than inst/lib to address an issue with install_github.
• R documentation now has additional whitespace to improve readability.
• R (overall) package help files are now available.
• R component handling of defaultValue fields is now similar to Dash for Python, fixing issues with rendering of components due to passing incorrect defaults.
• Removed dependency of JavaScript metadata generation for DashR on version.py.
• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.
• A new function assert_valid_wildcards is called when wildcards are available for a given component, to validate any wildcard input passed in via ... in the corresponding function formals in R.

[alexcjohnson]

It shouldn't be necessary to ignore this, though there are occasional issues.

[rpkyle]

K, this has been 🔪 ... as has the package-lock.json.

[T4rk1n]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

[T4rk1n]

Need to fix the error in generate_class_string

[T4rk1n]

That doesn't work.

>>>'setProps'+ ['**kwargs']
Traceback (mostrecentcalllast):
File"<input>", line1, in<module>TypeError: mustbestr, notlist

Suggested change

	p!='setProps'+ ['**kwargs']
	pnotin ['setProps', '**kwargs']

[alexcjohnson]

Oh that's not quite it either... the p not in [...] or p != ... clause is a filter in an iterator - in the python generator code:

dash/dash/development/_py_components_generation.py

Lines 118 to 126 in e72f483

	default_argtext+=", ".join(
	[('{:s}=Component.REQUIRED'.format(p)
	ifprops[p]['required'] else
	'{:s}=Component.UNDEFINED'.format(p))
	forpinprop_keys
	ifnotp.endswith("-*") and
	pnotinpython_keywordsand
	pnotin ['dashEvents', 'fireEvent', 'setProps']] + ['**kwargs']
	)

note the extra [...] from immediately after .join( to right before + ['**kwargs'] that turns this into a list that we can then append '**kwargs' to by adding a second list. I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

[rpkyle]

I'm assuming in R **kwargs doesn't mean anything, but there's some other feature to play the role of allowing arbitrary extra named arguments?

@alexcjohnson Correct. For the wildcards, I've used ellipsis (aka \dots, ...) for this purpose. It seems to be working to pass in an arbitrary number (including zero) of wildcard arguments.

[alexcjohnson]

I don't understand the package-lock.json, there's no package.json in dash. 🔪

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

[rpkyle]

I don't understand the package-lock.json, there's no package.json in dash. hocho

Hah too funny! Right, dash is the one repo that doesn't use npm at all. Oh well, sounds like @rpkyle sorted this out :)

I'm glad I've somehow fallen into the component management pipeline on the Python side as well, because for all the bumps and bruises, I'm certainly learning a few things.

[rpkyle]

• Use modified version of Mark Amery's byteify function to avoid storing strings from JSON as Unicode in Python 2.x, so that lists of strings in components should be identical in appearance across versions.

If it's possible to have a look at my recent changes and let me know if they are acceptable, and what further refinements are needed, that'd be great.

N.B. I ran into an error while testing the R component generation in Python 3 I hadn't seen previously:

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

I attempted to address this by wrapping props.keys() with list;

dash/dash/development/_r_components_generation.py

Line 134 in 01b6d9d

prop_keys=list(props.keys())

dash/dash/development/_r_components_generation.py

Line 280 in 01b6d9d

prop_keys=list(props.keys())

Component generation appears to be successful for both languages, and using Python 2 and 3; will look a bit more tonight to confirm.

@alexcjohnson@T4rk1n@rmarren1

[alexcjohnson]

I attempted to address this by wrapping props.keys() with list;

Yeah, .keys() and various other things return iterators instead of lists in py3, that one continually trips me up / annoys me... you've got the correct solution.

[T4rk1n]

File "dash/dash/development/_r_components_generation.py", line 282, in write_help_file for item in prop_keys[:]: TypeError: 'odict_keys' object is not subscriptable

Yes, dict.keys() returns a list in python 2 and a generator in python 3 so you need to cast to list.

[T4rk1n]

💃

[T4rk1n]

⏪ Sorting the key reorder the keys, the ordered dict will keep the right order alone.

[rpkyle]

@T4rk1n If PRs #439 and #91 look ready to go, mind quickly checking this one also? It should be somewhat straightforward.