Giter Club home page Giter Club logo

formbuilder's Introduction

Formbuilder

Build Status

If you want to try it out, have a look at the demo page

Or deploy it on Scalingo in a single click on this button:

Deploy to Scalingo

Scalingo offer a 1 month free trial then 7.20โ‚ฌ / month.

Installation

To run the formbuilder locally, you can issue the following commands:

$ git clone https://github.com/Kinto/formbuilder.git  
$ cd formbuilder  
$ npm install
$ npm run start  

You also need to have a Kinto server greater than 4.3.1 in order to store your data and less than 11.0.0 for an out-of-the-box experience (when basicauth was removed by default). The latest version of Kinto at the time was 9.2.3. If you don't already have Kinto, follow the installation instructions. Also, see the changelog.

Configuration

It's possible to configure a few things, using environment variables:

  • PROJECT_NAME is the name of the project. Defaults to "formbuilder".
  • SERVER_URL is the URL of the kinto server. It's default value depends on the environment that's being used (development, production, etc.)

How can I get my data back?

All the data generated by the formbuilder is stored in a Kinto instance. As such, you can request the data stored in there.

When you generate a form, you're actually generating two tokens:

  • the adminToken, that you need to keep secret, giving you access to all the submitted data;
  • the userToken, that's used by users to find back the proper form.

One interesting property of the userToken is that it is actually half of the admin token !

With that in mind, let's say we've generated a form with an adminToken of 152e3b0af1e14cb186894980ecac95de. The userToken is then 152e3b0af1e14cb1.

So if we want to have access to the data on the server, using curl, we need to authenticate as the admin (using BasicAuth with form:{adminToken}):

$ SERVER_URL="http://localhost:8888/v1"
$ ADMIN_TOKEN="152e3b0af1e14cb186894980ecac95de"
$ FORM_ID="152e3b0af1e14cb1"
$ curl $SERVER_URL/buckets/formbuilder/collections/$FORM_ID/records \
   -u form:$ADMIN_TOKEN | python -m json.tool
{
    "data": [
        {
            "how_are_you_feeling_today": "I don't know",
            "id": "7785a0bb-cf75-4da4-a757-faefb30e47ae",
            "last_modified": 1464788211487,
            "name": "Clark Kent"
        },
        {
            "how_are_you_feeling_today": "Quite bad",
            "id": "23b00a31-6acc-4ad2-894c-e208fb9d38bc",
            "last_modified": 1464788201181,
            "name": "Garfield"
        },
        {
            "how_are_you_feeling_today": "Happy",
            "id": "aedfb695-b22c-433d-a104-60a0cee8cb55",
            "last_modified": 1464788192427,
            "name": "Lucky Luke"
        }
    ]
}

Architecture of the project

The formbuilder is based on top of React and the react-jsonschema-form (rjsf) library.

It is also using redux to handle the state and dispatch actions. If you're not familiar with it, don't worry, here is an explanation of how it works.

A quick theory tour

With react and redux, components are rendering themselves depending of some state. The state is passed to a component and becomes a set of props.

States aren't all stored at the same place and are grouped in so called stores (which are containers for the different states).

Now, if one needs to update the props of a component, it will be done via an action.

An action will eventually trigger some changes to the state, by the way of reducers: they are simple functions which take a original state, an action and return a new version of the state.

Then, the state will be given to the components which will re-render with the new values. As all components don't want to have access to all stores, the mapping is defined in a "container".

Yeah, I know, it's a bunch of concepts to understand. Here is a short recap:

state : The state of the application. It's stored in different stores.

actions : triggered from the components, they usually do something and then are relayed to reducers in order to update the state.

reducers : Make the state of a store evolve depending a specified action

containers : Containers define which stores and actions should be available from a react component.

How are components organised ?

At the very root, there is an "App" component, which either:

  • renders a "mainComponent"
  • renders a sidebar (customisable), the notifications and a content (customisable)

It is useful to have such a root component for the styling of the application: header is always in place and the menu always remains at the same location as well, if there is a need for such a menu.

There are multiple "screens" that the user navigates into, which are summarized here.

This might not be completely up to date, but is here so you can grasp easily how things are put together in the project.

Welcome screen

There is a Welcome component which is rendered as a mainComponent.

<App>
  <Welcome />
</App>

Form edition

This is the "builder" part of the formbuilder.

On the left side, you have a FieldList component and on the right side you have the components. It's possible to dragndrop from the fieldlist to the form.

Each time a field is added to the form, the insertfield action is called.

<App>
  <Header />
  <NotificationList />
  <FieldList>
    <Draggable />
    <Draggable />
    ...
  </FieldList />
  <Form>
    <EditableField>
      <FieldPropertiesEditor /> or <SchemaField />
    </EditableField>
    <Droppable />
  <Form />
</App>

The form is actually rendered by the rjsf library using a custom SchemaField, defined in components/builder/EditableField.js.

Form created confirmation

Once the form is created, the user is shown the FormCreated view, with a checkbox on the left side. This has two links to the AdminView and the UserForm views.

<App>
  <Header />
  <NotificationContainer />
  <Check />
  <FormCreated />
</App>

Form administration

The form admin is where the answers to the forms can be viewed. It should be viewable only by the people with the administration link.

<App>
  <AdminView>
    <CSVDownloader />
  </AdminView>
</App>

Form user

The UserForm is what the people that will fill the form will see.

<App>
  <UserForm>
</App>

formbuilder's People

Contributors

adamjhamer avatar almet avatar andydhobbs avatar bastnic avatar dirtyf avatar etiennem avatar jimojon avatar n1k0 avatar natim avatar quentinroy avatar rlecellier avatar sahildua2305 avatar simon-previdente avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

formbuilder's Issues

Return null values when no answers for nullable fields

With JSONSchema it is possible to set a empty value as Nullable.

{
   "type":"object",
   "properties":{
      "user":{
         "type":"object",
         "properties":{
            "profileType":{
               "type":["string", "null"],
               "enum":[
                  "INTERNAL_SHORT_PROFILE",
                  "EXTERNAL_SHORT_PROFILE",
                  "DEMO_SHORT_PROFILE"
               ]
            },
            "userId":{
               "type":["string", "null"]
            },
            "email":{
               "type":["string", "null"]
            },
            "photoId":{
               "type":["string", "null"]
            },
            "statusPhrase":{
               "type":["string", "null"]
            },
            "country":{
               "type":["string", "null"]
            },
            "city":{
               "type":["string", "null"]
            },
            "company":{
               "type":["string", "null"]
            },
            "jobTitle":{
               "type":["string", "null"]
            },
            "presenceStatus":{
               "type":["string", "null"],
               "enum":[
                  "OFFLINE",
                  "AVAILABLE",
                  "BUSY",
                  "AWAY",
                  "HIDDEN"
               ]
            },
            "emails":{
               "type":"array",
               "items":{
                  "type":"object",
                  "properties":{
                     "email":{
                        "type":["string", "null"]
                     },
                     "validated":{
                        "type":"boolean",
                        "required":true
                     },
                     "default":{
                        "type":"boolean",
                        "required":true
                     }
                  }
               }
            },
            "phones":{
               "type":"array",
               "items":{
                  "type":"object",
                  "properties":{
                     "rawPhoneNumber":{
                        "type":["string", "null"]
                     },
                     "e164PhoneNumber":{
                        "type":["string", "null"]
                     },
                     "validated":{
                        "type":"boolean",
                        "required":true
                     },
                     "validable":{
                        "type":"boolean",
                        "required":true
                     },
                     "default":{
                        "type":"boolean",
                        "required":true
                     }
                  }
               }
            },
            "tags":{
               "type":["array", "null"],
               "items":{
                  "type":["string", "null"]
               }
            },
            "editable":{
               "type":"boolean",
               "required":true
            },
            "firstName":{
               "type":["string", "null"]
            },
            "lastName":{
               "type":["string", "null"]
            },
            "nickName":{
               "type":["string", "null"]
            }
         }
      }
   }
}

When types contains null, we could add a checkbox to let people set the field value to null.
If the ckeckbox is checked, the field should not be editable.

Add an option to download a the admin and user URLs as text

In the Daybed formbuilder, we had an option to download the generated URLs as a text file, using a Content-URL link.

The code in daybed did:

var TEMPLATE = (
  "{{formName}}\n" +
  "---------------------\n" +
  "\n" +
  "  * User Link: {{userlink}}\n" +
  "  * Admin Link: {{adminlink}}"
);

var filename = "form-" + this.props.metadata.formName + ".txt";
var fileContent = "data:text/plain;base64," + btoa(
TEMPLATE
  .replace("{{userlink}}", this.props.userLink)
  .replace("{{adminlink}}", this.props.reportLink)
  .replace("{{formName}}", this.props.metadata.formName);

downloadButton = <a download={filename} href={fileContent} className="btn btn-primary pull-right">Download</a>;

Encrypt data on client side

For this, we would need to generate an encryptionSecret on the client side, and pass it to the users using a hash in the URL.

Then, all records could be encrypted with it, before being stored.

The problem with this approach is the fact that validation cannot happen server side, but I believe that could be an interesting mode, depending on what you want to achieve.

I would be interested in having thoughts about this approach. cc @Natim @leplatrem and eventually a security feedback from @jvehent

New edition approach

I would be an advocate to rethink the whole field edition process (yeah I know, big thing). I do think it can be made much simpler and handier. Google Form, for example, does way better :-/, especially in their last version that implements a quasi-wysiwyg approach.

This is not an easy design, and I do think that this is one that cannot be efficiently discussed in a forum (or similar). A "real-world" design session is likely to help much.

Add a handle for the dragndrop

The way the drag and drop is currently used is not very user friendly. One way to solve it is to add a handle to the components, and have only this handle able to trigger the dragndrop.

Number field defaults

We shouldn't set number field schema defaults to 1-100 integers and find a way to offer free form input by default.

Replace the alert dialog during deletion

Currently, when a widget is deleted, an alert dialog is shown to the users. We should find another mechanism instead.

I like the idea to change the label of the "delete" link to "are you sure"? and let the user click again, or display the user with a "cancel" link.

Have better labels

Currently the label of new form element is generated when added, and we end up with IDs such as field_8117647. Rather than that, it could be useful to show something such as "Question 1", "Question 2" per default.

Fix the back button

The "back" button currently goes back to the homepage, which isn't the intended behaviour.

"Too many redirections" on Opera

Hi,
When accessing on https://www.fourmilieres.net/ Opera failed with a "Too many redirections" error.
Opera 37.0.2178.43 - Mac OS X 10.9.5 64-bit

After opening the debug console and refreshing the page, things are better, the page is loading but still with many redirections.
capture d ecran 2016-06-01 a 10 56 14

Add widgets on simple click

Currently it works using dragndrop. We should keep the dragndrop for the reorganisation of the widgets but we don't need to dragndrop them when they're first added.

Stop the spinner on error

Currently, when a server isn't responding and an error is displayed after a form submission, the spinner is still spinning. We should stop it when an error occurs.

Add support for fieldsets

When working on v1, we made the decision to remove the support for fieldset, but it's indeed a good feature.

In order to integrate it properly, we would need to:

  • Decide on the UX we want to have for the fieldsets: do we want to have them editable or not?
  • If we decide to have them editable (I believe it would be a good thing), we then need to have this behaviour working properly: an edited field should remain edited and not be replaced by the default value.

Start with all fields in edit mode.

I think it could be useful to have the fields in edit mode as soon as they are added. I did some testing and changing edit to true by default isn't enough because the state isn't persisted.

What do you think about storing this information in the store and passing it as props rather than having the component directly handle this with state? Otherwise the default value will always come back (currently, if you are in edition and add a new field then the field you were editing will come back to the edit:false state).

Abstract integration with the storage server

Once #12 will have landed, it will be possible to store the data generated by the formbuilder to kinto. That would be great to be able to use a different storage mechanism (couchdb, cozy, etc.).

In order to do this, an abstraction needs to be done for the storage, and the storage layer could be configured from the config.js file.

Add a way to specify the kinto server to use during form creation.

Users should be able to specify which kinto server they want to use during the creation of the form (e.g. it shouldn't only be a configuration of the application itself).

I can foresee a world where it would also be possible to not only send the schema to the server, but also the complete application that consumes the schema (using kinto-attachments), and then maybe another plugin that would return the index.html page if the collection is accessed via a browser (By checking the Content-Type header + the presence of an attached file).

This way, form consumers could just have to converse with the storage server to store data there.

Handle kinto permissions

The current implementation of #12 uses the same credentials for the form creator and for the consumers. Instead, we should generate an authentication token for the admin and put it in the URL to the admin view.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.