Skip to content

Home

Jump to bottom Edit New page
insin edited this page Jan 4, 2015 · 106 revisions

Development

0.11

TBD

Feature Grab-Bag

Infrastructure

Migrate off qqunit for cross-environment testing.

Break everything up into individual modules and publish to npm as flattened modules

  • People who want to save on dependency file size can directly import only what they need.

Everywhere

Deprecate asDiv(), asTable() and asUl()

  • Have render() take arguments to be used as props for the default React component

Integration between React components and Widgets - e.g. make a CharField use a Widget which renders a component which can mask input based on a format passed to the Field.

  • Add a BoundField method which returns the attributes it would have passed to the widget for use with JSX spread operator

Come up with a better/more intuitive name for BoundField - its name was never day-to-day API in Django due to Python having an iteration protocol and . vs [].

Documentation

  • Split guide sections up into client/server pages
  • Retain most of the existing docs as the server pages - they're focussed on usage of isValid() etc. and use examples which are equivalent to POST data.
  • Extract and rewrite client docs into client pages, with a focus on interactive validation and typical use cases around it, as it's going to be the default mode of operation. No POST-like data examples!

Create a "Field" which wraps a FormSet, allowing you to manage a list of items with a Form.

Disabled/hidden fields

  • Add Field properties for hiding a field entirely or rendering its widget as disabled.
  • Validation/cleaning should skip over disabled/hidden fields
  • Pro: Enables future dynamic use of these, as fields are always present rather than being added or deleted in the constructor

Client

Add more special case events for text inputs

  • onFocus should be able to clear code=required errors

Add the ability to specify success messages for fields.

  • Should message types be consolidated?
  • Should help text be treated as another message type along with error and success?

Does form.addError() need to remove the corresponding field from cleanedData?

  • When used in clean() to mark a particular field as invalid, the field's cleanedData must have been valid up to that point. It forces the user to go back to the field. Scenario: password and confirm. When they don't match use clean() to show the error message on confirm. Now if the user edits password to match confirm, validation won't work, as there's no cleanedData for confirm.

FileFields need an overhaul on the client side - there are a growing number of Widget.prototype flags which could potentially be used by custom Widgets, but in the core library are only there for special handling of FileFields.

  • See https://github.com/insin/newforms/wiki/Client-side-FileField-Enhancements
  • Need to get a better picture of what typical file input usage is in React apps - I doubt many people will be using them in s submitted via POST, but that's the original use case this API was designed around.
  • Resetting file inputs - can't change the value (in all browsers) due to security restrictions!
    • Keep a number somewhere which is used only in file input key attrs and increment it when an attempt is made to update a file input, to force React to recreate it?
      • form.fields is effectively part of Form instance state, as it's deep-cloned from form.baseFields - could add an own property to FileField for this.
      • After prototyping, may need to introduce (more) special case API: Field.prototype.renderKwargs()

Is there a common approach that could be used to tweak particular field or widget properties on the fly?

  • Dynamic hidden/disabled fields
  • Dynamic field choices
  • These would be reacting to a change in...?
    • initial/data
    • cleanedData
    • any additional state the user needs to pass in
      • Example: Showing/hiding form fields based on external controls/state.

Add support for populating data onChange without providing a containing <form>.

Server

Get usage in String template engines working again

  • toString() methods which are only included in a specific build and call Reaact.renderComponentToString, wrapping with React.createClass as neccessary?
  • Stick with server/browser flag or move to separate builds, source never directly used?
  • Version solely for use with server-side string-based templates? Created an html branch which avoids direct references to React.DOM

Bonus

Theoretically, it should be easy to persist form state should the user refresh or accidentally navigate away - put form.data in localStorage in the onStateChange callback, pass it as initial if present when creating initial component state, clear it after successfully using form.cleanedData.

  • Investigate and document - any helpers which could be provided?

Externalise mutable form state - a form/formset should provide a reference to an object to be set in a component's state.

  • Changes to properties within this object by the form/formset should use React.addons.update().
  • Form would need to be passed a callback which calls setState() for all data/error changes.
  • This would allow easier creation of form-wrapping components which can skip rendering if nothing has changed.
  • For FormSets, with this in place can we create a single form instance and reuse it, tweaking a variable indicating a virtual index within the set? We just then need to keep lists of cleanedData and errors which are actually held independently of the workhorse instance.
Add a custom footer
Add a custom sidebar
Clone this wiki locally