Added isSerializable and SERIALIZABLE to Field

[BeksOmega]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide

The details

Resolves

Work on #1623

Proposed Changes

Adds a SERIALIZABLE property to fields. Adds an isSerializale function that handles warning & backwards compatibility logic.

I also reorganized the test-blocks toolbox so now it looks like this:

Reason for Changes

Sometimes you would want to programmatically modify a field, but not allow users to modify it, and save it to XML. Before you would have to create a mutator for this purpose. Now you can simply use a serializable field.

Test Coverage

I added unit tests! I added tests for the isSerializable function to make sure it works in a backwards compatible way. I also added serialization tests to make sure the XML for different fields was comming out correctly.

Here's also a quick example of some fields being serialized and deserialized:

Here's the generated XML for that example:

<xml xmlns="http://www.w3.org/1999/xhtml">
  <variables>
    <variable type="" id="o(EVLYWaZFZca|N:K.7I">not item</variable>
  </variables>
  <block type="test_fields_angle" id="mkWW9%.I_@;R#$W[H{PM" x="38" y="113">
    <field name="FIELDNAME">89</field>
  </block>
  <block type="test_fields_date" id="flqjVdY:q[i9i9quPeNH" x="37" y="163">
    <field name="FIELDNAME">2019-04-18</field>
  </block>
  <block type="test_fields_checkbox" id="ek{drzs2vnp^RIzb[~_." x="38" y="212">
    <field name="CHECKBOX">FALSE</field>
  </block>
  <block type="test_fields_colour" id="0kbOz)J7$}kH;aG$/7ku" x="38" y="263">
    <field name="COLOUR">#33ff33</field>
  </block>
  <block type="test_fields_text_input" id="f%yfBd#74I3,;do8vGAu" x="37" y="312">
    <field name="TEXT_INPUT">not default</field>
  </block>
  <block type="test_fields_variable" id="2![yICR}hguA1=0)-x`^" x="37" y="362">
    <field name="VARIABLE" id="o(EVLYWaZFZca|N:K.7I" variabletype="">not item</field>
  </block>
</xml>

Tested on:

• Desktop Chrome

Additional Information

SERIALIZABLE is false by default. This is so that it is backwards compatible with any non-editable fields that people had created in the past.

The problem with this is that if you had created a custom editable field before you'll get a warning message when it goes to serialize, because EDITABLE is true and SERIALIZABLE is not, which is an invalid state. It still serializes! But you will get that warning. I don't necessarily /like/ this but it's the best solution I could come up with.

Also I'm planning on adding field_label_serializable and field_image_serializable fields, but the field_label_serializable stuff started cluttering up this PR and the fromXML toXML change needs to get in before field_image_serializable can be added.

[rachel-fenichel]

We don't have mocha running on our server yet--are you running these tests locally?

[rachel-fenichel]

Since EDITABLE defaults to true on fields, you don't need to redeclare it on each of these classes. You only need to declare it for classes that set it to false. The inverse is true for SERIALIZABLE.

[BeksOmega]

Fixed.

[rachel-fenichel]

One lint error on travis: https://travis-ci.org/google/blockly/builds/521780332#L536

[NeilFraser]

One lint error on travis: https://travis-ci.org/google/blockly/builds/521780332#L536

That console log looks appropriate and useful. What's Travis' logic that flags this console usage and not others?

[BeksOmega]

We don't have mocha running on our server yet--are you running these tests locally?

Yes I added them to your handy-dandy index.html file. Here's a pic of my added tests (ignore the variable fields tests):

[rachel-fenichel]

That console log looks appropriate and useful. What's Travis' logic that flags this console usage and not others?

Not sure, actually. it should all be running with the same eslint rules, since our eslintrc is in our root directory, and that has the no-console rule disabled. Weird.

[BeksOmega]

Ok @rachel-fenichel I changed the mocha eslint config to extend the root one, and then I fixed the lint errors in the other mocha files. I can separate those changes into a separate PR if you like, otherwise I think this is good to go.

[rachel-fenichel]

Awesome, thanks for tracking that down.