Skip to content

Home

Jump to bottom Edit New page
Jonny Buchanan edited this page Jan 20, 2015 · 106 revisions

Development

0.11

  • Remove asDiv(), asTable() and asUl().
    • A lot of test code needs to change, might also be the right time to migrate off qqunit for cross-environment testing.
  • ☑ Deprecate formsetFactory()
    • ☑ Rename BaseFormSet to FormSet, or add a FormSet constructor which can just be .extend()ed.
  • Modularise - break everything into individual modules and publish to npm as flattened modules.
    • Default require('newforms') should still give you the same grab-bag for back-compat.
    • Add some other collections, such as require('newforms/forms'), require('newforms/fields'), require('newforms/widgets')
    • People who want to save on dependency file size when bundling can directly import only what they need - in particular, you should never need to bundle FormSets if you're not using them.
  • Revisit when error messages get cleared - playing with some of the custom validation on the newforms-bootstrap grid example, cross-field, async and both validation is a mess of things appearing and disappering.
    • This behaviour was implemented before prevention of duplicate validation errors was in place - might have been a contributing factor.

Feature Grab-Bag

Everywhere

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 [].

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