wingspan / wingspan-forms Goto Github PK

This will make it easier to collaborate with Telerik

AutoField render():

<FormField fieldInfo={this.props.fieldInfo} isValid={this.props.isValid}>
                    <AutoControl
                        fieldInfo={this.props.fieldInfo}
                        value={this.props.value}
                        onChange={this.props.onChange}
                        dataSource={this.props.dataSource || this.props.fieldInfo.options} />
                </FormField>

take a look at line 28:
dataSource={this.props.dataSource || this.props.fieldInfo.options} />

we render an AutoControl which since we have options we get here:

if (fieldInfo.options) {
                controlProps.dataSource = this.props.dataSource || fieldInfo.options.dataSource;
                controlProps.valueField = fieldInfo.options.metadata.idProperty;
                controlProps.displayField = fieldInfo.options.metadata.nameProperty;
            }

And if we don't pass a dataSource prop to AutoField, we expect to fall back to fieldInfo.options.dataSource because of this:
controlProps.dataSource = this.props.dataSource || fieldInfo.options.dataSource;

but back in AutoField, this.props.dataSource || this.props.fieldInfo.options gives us an undesired dataSource prop.

changing line 28 of AutoField to: dataSource={this.props.dataSource || undefined} makes it do the right thing.

Should not set body {overflow: hidden} and the font stuff needs to be a separate css file

It can't ever work in the general case because it cannot handle function-as-prop.

This line can fail with "3" !== 3 in very confusing fashion

radio.props.checked = (radio.props.value === value);

This probably doesn't require a specific implementation of Cursors, it just requires any object that duck types to var cursor = { value: ..., onChange: ... }. The widgets themselves don't need to refine the cursor.

deprecated in favor of Cursors

Lack of this is causing perf issues in the TMF, this was left out on accident

Two reasons

1. reduce build time and procrastinate action on the "factorial subgrunt time" problem
2. the dependency isn't very important anyway

Works fine with underscore 1.6.

Could also change it to be >= 1.4, would probably work.

KendoDate -> KendoDatePicker
KendoDatetime -> KendoDateTimePicker
KendoTime -> KendoTimePicker
KendoNumber -> KendoNumericTextBox
KendoText -> TextBox (not actually a kendo-based widget)

This is needed so we can get lodash.cloneDeep. Unfortunately leaving underscore on the page as well requires the app to have a special require configuration which is easy to forget.

The way it's used, it means the widget's enable() or readonly() method is called even if the disabled/readonly properties don't change. This causes much needless DOM manipulation. Instead, we can do this in each widget's componentDidUpdate:

        if (this.props.disabled !== prevProps.disabled) {
            autoComplete.enable(!this.props.disabled);
        }
        else if (this.props.readonly !== prevProps.readonly) {
            autoComplete.readonly(this.props.readonly);
        }

UserPicker is more of an app-level concern, that can be restated in terms of an AutoComplete.

Uncaught TypeError: Cannot read property 'value' of undefined

(The kendo widget was never attached to the dom)

It's just a seemingly harmless warning now, but in the future will be an unsupported use case.

This happens as lodash.isEqual recursively iterates over this.props / nextProps and the props contain a component that hasn't been mounted yet.

I can reliably reproduce this in the tmf: Set up a document with multiple (at least 3?) indexes and click through the tab strip. As you click through and hit either the last or loop around to the first again, you get a wall of text of warnings in the console. The warnings don't appear again, presumably because the children are all mounted now. You can refresh the page to reproduce again.

PromiseButton should remove the dependency on Q and support any promise implementation that implements then() based on the Promises/A+ specification. This would support direct use of PromiseButton with jQuery and other libraries. It would also remove the need to have wingspan-forms depend on Q.

this.props.dataSource.fetch().then ...
Uncaught TypeError: undefined is not a function

This is necessary to support unit tests. The TMF will need to be upgraded as well.

I've implemented a first pass at this, though I have not attempted to generalize it. But that should be straightforward to move into WF when I find time.

These are the four grid controls:

• KendoGrid.js
• KendoGridPicker.js
• KendoGridPickerByButton.js
• KendoGridRadioSelectable.js

I doubt we need four. Probably one with a few props that configure behavior. For example, the radio vs. checkbox question could be determined by whether or not the grid supports multiple selections.
Also, we should use the kendo grid's built-in selection system, since it will better handle corner cases (like clicking on grid headers), and support keyboard-driven selection.

The "typeInfoModel" function in "kendoutil.js" does not belong in the forms library. It is very specific to the Wingspan TMF application and the server structures it uses. If we choose to make it open source, it should be in "wingspan-data".

Here is an email thread where Andrew and I brainstorm possible solutions. Just cleaning my inbox.

Andrew Goodale (Wingspan)
Feb 24

to me
I think that would be more deterministic, although I'm not sure what you mean by "manage the datasource by hand".
I know that kendo's combo tries to be smart, making secret requests for data when the value is set. I'm not a fan of magic like that, but I understand we need to work within what they do. Maybe the best choice, for "_Kendo_ComboBox", is to always pass the ID and let Kendo do its thing.

On Mon, Feb 24, 2014 at 9:43 AM, Dustin Getz (Wingspan) wrote:
so in both cases, we're going to bypass kendoCombo.value() and use kendoCombo.text() directly, and manage the datasource by hand?

On Mon, Feb 24, 2014 at 9:41 AM, Andrew Goodale (Wingspan) wrote:
You're not going to be able to have a library that dictates the server's data design choices - at least I don't think.
I guess what I'm trying to say is that the ComboBox would be happier if it didn't have to worry about this. Can we just externalize the whole issue, such that the ComboBox:

1. Always treats "value" as an opaque thing.
2. When it needs to render text for the value, it calls a function that's passed in. So the logic to determine how to display values is managed by the owner of the combo. Thus, whether the data is flat, joined, or whatever, the combo doesn't care.

On Mon, Feb 24, 2014 at 9:24 AM, Dustin Getz (Wingspan) wrote:
I am not sure how that would look. Can you elaborate a little more?

To recap the valueAs stuff:
if its always valueAsId, the object shapes are consistent (nothing joined) and always result in a datastore fetch. Thus all the code goes through the same "happy path" and there is more opportunity for abstraction. valueAsOption is the inline optimization which costs opportunities for abstraction because the business logic becomes coupled to the shape of the data, what is joined in and to which depth. So you couldn't build an AutoCrudApp for example.

On Fri, Feb 21, 2014 at 8:32 AM, Andrew Goodale wrote:
It's a little unusual. An alternative would be to allow an optional "valueRenderer" function, which would allow folks to handle any type of value. I can't remember all the reasons why a combo cares about the ID vs. Object issue, but it seems like it keeps the combo simpler to allow it to treat the value as opaque and let folks customize the rendering of the value.

If I was building a combo box from scratch, I would have "value" and "valueRender" props instead of "value", "idField" and "displayField".

AHG

On 20 Feb 2014, at 22:09, Dustin Getz (Wingspan) wrote:

I'm going to make the mode an explicit prop like mode={Modes.ValueAsId}.

If no mode is passed, it can default to "figure it out". I also am going to
add a console.warn every time this happens.

Can you think of any reason not to do this?

I am going to add some sort of typeToControl prop instead of as a global, and I will default it to the current configuration for backwards compatibility. Future use cases should declare an app specific TmfAutoField that calls to AutoControl with the typeToControl prop filled in. This also fixes the case of formFieldLockable code on all of our forms.

try , or any datepicker in the sandbox

Still has a lot of app-specific logic in it. Perhaps it's better suited to be a thinner wrapper around a kendo auto-complete.

I've already split out the custom checkbox markup into a separate .css build artifact (I did this back in May)

I'd like to split out the rest of the custom styles into logical .css artifacts where sensible. Not sure how hard this will be. I have access to Cameron. If we do it right it will have minimal TMF impact, you'll just have to add another .css import to the final build.

I believe. Double check, then remove options prop from Carousel

Jasmine + jsdom seems to be the answer

It includes a large number of unused methods that we don't want to document and maintain.

When the value for a KendoDate control is set to null, kendo does not change the current month in the calendar widget. The user is presented with the month for the prior value, instead of today's month. This appears to be a bug in the widget code, but we can workaround it.

it is useful outside of wingspan-forms

Just ran across this project in a github search and it looks pretty cool. We're assembling a page of quality React-based libraries and I think this is a great candidate to include. When you're ready just open an issue or send a PR!

https://github.com/facebook/react/pull/1011/files

http://wingspan.github.io/wingspan-forms/examples/sandbox/

From the code, they are maybe a JS date or maybe the string 'NOW'

see TMF-5049. Workaround is to set a key prop that changes whenever the datastore changes, so the combo fully unmounts and remounts.

I dont believe the TMF actually uses the KendoGrid internal selection state, we handle that out of band.