I need some help designing a React app singe page app.
I want to show and let the user edit (via form inputs) a complex JSON structure (with known shape), but I'm having trouble picturing how to bind the values in my generated form to the data structure. The JSON structure is static, I just want to let the user edit values, not the structure itself.
Some of the values depend on other values in the structure (e.g. the max value of a field is specified in other field). The data has nested structures but they do not map 1:1 to my components (I don't control the input) which makes handling more complex (deep components can change surface values).
For example purposes:
data.json
{
"age": 12,
"maxAge": 100,
"name": {
"first": "John",
"last": "Doe"
},
"dogName": "Foo"
}
main.jsx
ReactDOM.render(<Editor data={data} />, mount);
Editor.jsx
<form>
<Person data={props.data} />
<Text defaultValue={props.data.dogName} />
<h2>Settings:</h2>
<Number defaultValue={props.data.maxAge} />
</form>
Person.jsx
<fieldset>
<Text defaultValue={props.data.name.first} />
<Text defaultValue={props.data.name.last} />
<Number max={props.data.maxAge} defaultValue={props.data.age} />
</fieldset>
Handling each and every field manually with change events seems too complex, tiresome (I have tens of fields per component), and error-prone... and I'm not even sure how to propagate the changes to the top-level component from the inner ones.
What are the alternatives?
For an official guide: Thinking in React
I believe the above guide can help walk you through some of the challenges that you are facing.
For your first point: I would use state to hold the information. You can do "two way" data binding to have the form represent your data and the data represent your form. You can also use some form of onChange function calls to update the data that relies on other inputs.
Section 5 of the linked guide goes over propagating data up the chain (ie person -> editor) using callbacks.
If this is going to potentially evolve into a larger project, I would suggest looking into Flux for a MVC type front end with React as the View.
Related
I have a form, this form needs to post some data to my backend. With flux, what is the best practice for doing this, use a store?
My issue with using a store is that I have a sub component inside of my form that allows me to select a number 1-5 with buttons. I wanted that component to be reusable, but if i use a store, I have to hard code the store into the child component which means I cant really use it elsewhere. Instead do I just set the parent state from the child?
If anyone can point out some good tutorials or examples of react/flux forms let me know.
In my opinion any back end interaction should be done by using actions, but...
if you want to use store anyway then you can create additional attribute (prop) in your sub-component which will be a function (f.e. onChange) which should be passed from parent component as prop (this function should set data in store). Then you can reuse this component, because only parent needs to have access to store.
So in subcomponent:
onButtonClick(e) {
this.state.value = e.target.value;
if (this.props.onChange) this.props.onChange(e.target.value);
}
<div>
<button onClick={this.onButtonClick.bind(this)} value="1">1</button>
<button onClick={this.onButtonClick.bind(this)} value="2">2</button>
<button onClick={this.onButtonClick.bind(this)} value="3">3</button>
<button onClick={this.onButtonClick.bind(this)} value="4">4</button>
<button onClick={this.onButtonClick.bind(this)} value="5">5</button>
</div>
and in parent:
setMyStoreState(value) {
store.setNumber(value);
}
<Subcomponent onChange={this.setStoreState.bind(this)} />
or something like this.
Code not tested, but you should get the idea.
I'm using OpenRasta to create a Survey application.
I have a SurveyResource that is accessible at /surveys/{id} and editable at /surveys/{id}/edit
I'd now like to add questions to the survey, as that is the point of a survey, but I'm not sure what the most restful way of doing this is and how to set it up in OR.
I'm thinking I should have a QuestionResource (that has details of the question type, question text, etc) and it should be posted to /surveys/{id}/questions and handled by a question handler, but I can't work out how to configure OR.
I've pushed my project onto github at https://github.com/oharab/OpenSurvey/tree/add_question_to_survey
Can anyone help me?
Ben
it depends on the way you want to model your resources. It's perfectly possible that you'd never explicitly provide access to a single question, and would modify the entire survey document, like so:
PUT /surveys/123
<survey>
<link rel="update" href="/surveys/123" method="PUT"
type="application/vnd.mycorp.survey+xml" />
<question id="age">
<label>How old are you?</label>
<select>
<option>0 - 5</option>
<option>6 - 10</option>
<option>10 - 13</option>
</select>
</question>
</survey>
If you go this route, you could even use HTML, or HTML 5 for your content so it's easy to consume by clients. Now you're just modifying the entire survey document at once.
Alternatively, you might want to separately address each question, giving them an individual URI, which I think is what you're talking about, like so:
GET /survey/123
<survey>
<link rel="add-question" href="/survey/123/questions"
type="application/vnd.mycorp.surveyquestion+xml" method="POST" />
<question>
<link rel="delete" href="/questions/123-age" method="DELETE" />
<link rel="update" href="/questions/123-age" type="application/vnd.mycorp.surveyquestion+xml" method="PUT" />
<label>How old are you?</label>
<select>
<option>0 - 5</option>
<option>6 - 10</option>
<option>10 - 13</option>
</select>
</question>
</survey>
Neither of these is more RESTful than the other, the difference is only in granularity of call. If you need the granularity of the latter, then configure yourself a separate handler per resource as in
using(OpenRastaConfiguration.Manual)
{
ResourceSpace.Has.ResourcesOfType<Survey>().AtUri("/survey/{id}").HandledBy<SurveyHandler>();
ResourceSpace.Has.ResourcesOfType<Question>().AtUri("/questions/{id}").HandleBy<QuestionHandler>();
}
I'm new to Core Data and databases in general. Now I need to parse a XML and store the contents in Core Data. The XML looks something like this:
<books>
<book id="123A" name="My Book">
<page id="95D" name="Introduction">
<text id="69F" type="header" value="author text"/>
<text id="67F" type="footer" value="author text"/>
</page>
<page id="76F" name="Chapter 1">
<text id="118" type="selection">
<value data="1">value1</value>
<value data="2">value2</value>
<value data="3">value3</value>
</text>
</page>
</book>
<book id="124A"...
From my understanding I would need four Entities, like "Books", "Book", "Pages" and "Text". I wonder how to set the relationships correctly and how to add for example a Page object to a Book object and how to retrieve a Text object attribute's value? The tutorials I have found mostly deal with one Entity so I didn't really get the idea.. Gtrateful for any help!
No, you'd need three entities. You can think of "Books" as the CoreData database you're using. The CoreData database then includes a number of entities called book.
I think the data model you have is a bit weird, but I guess it makes sense for your application. To map it to CoreData I would:
Add the entities Book, Page, Text
Add a bookId, pageId, textId to them, respectively.
Then add a relation from Page to Book, and from Text to Page.
By then you should be able to print out a whole book by asking for all Pages that have
Book = the book you're interested in
and then order all those Pages by their pageId
and in order, ask for all texts that have
Page = the current page
then order those Texts by their textId.
What might be a problem is that a Text can have multiple Values, as seen in your XML above. You could use this by adding another entity called Value, but I would probably solve it by adding the attributes "value" and "type" to the Text entity directly. (You could then use "value" as a second sort key when printing out a page.
Check out these links:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CoreData/
http://developer.apple.com/cocoa/coredatatutorial/index.html (for regular Cocoa, but the same principles hold so this should help)
I have a large form that consists of all the input (text, checkbox, radio, etc...), I have them grouped together in a fieldset tag and a legend for each feildset. Each input has a label associated with it as well. My question is what is the best approach to display the information on one screen and take advantage of the horizontal real estate the user might or might not have?
I would love it to be all CSS with minimal (if any) table layout(s) as I think tables are for tablature data and not presentation. CSS3 and HTML5 are welcome as well.
Also I would like to have the ability to add branding as this might need to look like another site instead of the original site developed for.
What would be the best approach for this? I have the idea I would use li tags to do the horizontal look but I would like to break to the next line at the end of the screen (Think no scrolling horizontal but vertical is okay)
CSS Novice looking for design pattern advice
This is an example but I think I have around 50 fields
<!DOCTYPE HTML>
<html>
<head>
<title>Large Form</title>
</head>
<body>
<form action="">
<fieldset>
<legend>***</legend>
<label for="fname">First Name</label><br />
<input type="text" name="fname" id="fname" value="" /><br /><br />
<label for="lname">Last Name</label><br />
<input type="text" name="lname" id="lname" value="" /><br /><br />
<label for="gender">Gender</label><br />
<select name="gender" id="gender">
<option value="">-- select</option>
<option value="male">Male</option>
<option value="female">Female</option>
</select>
</fieldset>
<br />
<input type="submit" value="Submit" />
</form>
</body>
</html>
The first thing that comes to mind is that you want to remove the <br/> tags from the form. If you need vertical space, use CSS padding and margins since they're easier to change and make spacing consistent.
With that out of the way, other than branding (which will influence the look and feel of the form the most) the things you want to consider the most are accessibility and ease of use. Your use of labels and unwillingness to use tables for layout are a good start for accessibility so I'm not going to mention it further.
For ease of use, you'll need to make sure that each field can be tabbed to (in an order that makes sense), has a clear, meaningful label, has no unnecessary validation rules (such as forbidding whitespace in a phone number - don't force the user to clean data that can be cleaned automatically) and those validation rules that are necessary have clear, easy to understand messages that appear, ideally, as the user is entering the data rather than waiting for the user to submit the form.
Each of your field sets should be visually grouped either by colour, with a border or some other method. Individual field set should not be broken up, but different field sets can be separate from each other as long as they are contextually different (like address versus interests, for example).
Since you're already grouping field sets, you can use them as your basic unit of page layout. Each set could be floated, for example, in order to maximimize horizontal usage regardless of the user's browser width. As long as the sets are visually distinct enough and are clearly labelled there shouldn't really be any issues with that.
If consistency is more your thing, then each field set should be separated from each other vertically. That would make sure the form is ordered and laid out the same way for every user. Again, the important thing is visual consistency and ease of use. Users are used to forms being laid out vertically so the wasted horizontal space of doing it that way shouldn't be a very big concern.
Just remember: you're making something that should be easy to use and not frustrating. The position of fields should reflect that: they should be natural, grouping like fields together and separating groups of like fields from dissimilar fields. As long as you're keeping that in mind you're probably in good shape.
And don't forget to do some quick usability tests to make sure your validations make sense and are clear.
Have a look at CSS3 grid positioning. It has a clear but powerful syntax, e.g. from the link:
body {
grid-columns: * * (0.5in * *)[2];
grid-rows: 20% *;
columns: 3;
column-gap: 0.5in;
}
Elements use gr units to choose their grid cell:
img {
position: absolute;
left: 2gr;
width: 3gr;
}
You would only have to give an id to your fieldsets then set their position and extents in your style file.
One of my favorite ways to group large forms is with the jQuery style accordion. It allows you to abstract the form into key groupings, keep the form all on one page, and eliminate the need for page scrolling; all with an intuitive user interface.
A good example of this is the Barnes & Noble checkout form process.
Check out CSS Flexbox for some liquid flexibility withing you design sets. I would also recommend picking a "style" and sticking with it. Agree with Welbog.
I guess that if you have a form with 50 fields, you surely have to split it to themed tabs. Say 3 to 5 tabs. They can be implemented by Javascript.
You may want to save input data on-the-fly, because the user may need a long time to finish the form, so there is bigger possibility that he will catch a loss of internet connection or some other factor, that will erase his half-finished form, which would probably dissapoint him and leave your site.
Also consider that user has to have a place for his eye to rest, so be sure to make enough blank room between inputs.
im pretty new to jQuery, and i dont know how to do that, and if it can be done without editing manually the plugin.
Assume to have a simply form like that:
<form action="page.php" method="post">
Name: <input type="text" name="Your name" id="contact-name" value="" />
Email: <input type="text" name="Your email" id="contact-email" value="" />
</form>
When you submit it, both in 'standard' way or with ajaxSubmit(), the values of the request take the label of the field name, so in the page.php i'll have:
$_POST['Your name'];
$_POST['Your email'];
Instead i'll like to label the submitted values with the id of the field:
$_POST['contact-name'];
$_POST['contact-email'];
Is there a way to do that with jquery and the ajaxsubmit() plugin?
And, maybe, there is a way to do it even with the normal usage of a form?
p.s: yes, i know, i could set the name and id attributes of the field both as 'contact-name', but how does two attributes that contain the same value be usefull?
According to the HTML spec, the browser should submit the name attribute, which does not need to be unique across elements.
Some server-side languages, such as Rails and PHP, take multiple elements with certain identical names and serialize them into data structures. For instance:
<input type="text" name="address[]" />
<input type="text" name="address[]" />
If the user types in 1 Infinite Loop in the first box and Suite 45 in the second box, PHP and Rails will show ["1 Infinite Loop", "Suite 45"] as the contents of the address parameter.
This is all related to the name attribute. On the other hand, the id attribute is designed to uniquely represent an element on the page. It can be referenced using CSS using #myId and in raw JavaScript using document.getElementById. Because it is unique, looking it up in JavaScript is very fast. In practice, you would use jQuery or another library, which would hide these details from you.
It is reasonably common for people to use the same attribute value for id and name, but the only one you need to care about for form submission is name. The jQuery Form Plugin emulates browser behavior extremely closely, so the same would apply to ajaxSubmit.
It's the way forms work in HTML.
Besides, Id's won't work for checkboxes and radio buttons, because you'll probably have several controls with the same name (but a different value), while an HTML element's id attribute has to be unique in your document.
If you really wanted, you could create a preprocessor javascript function that sets every form element's name to the id value, but that wouldn't be very smart IMHO.
var name = $("#contact-name").val();
var email = $("#contact-email").val();
$.post("page.php", { contact-name: name, contact-email: email } );
This will let you post the form with custom attributes.