JavaScript Objects

[rbu...@nfbconsulting.com]

Hey all,

I see there is an implementation for JavaScript Arrays as Blockly.JavaScript.lists. Is there any implementation or API for JavaScript Objects?

Warmly,

Ryan Busby

[Ryan Busby]

Update: I found goog.Object in blockly. I imagine if it doesn't exist I can use this API to build it : ^)

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ryan Busby Software Engineer

2501 East 28^th Street  Suite 111  Signal Hill, CA 90755

t 310.526.3425  f 310.405.0838

gbe...@nfbconsulting.com www.nfbconsulting.com

P Please consider the environment before printing this e-mail.

Important Confidentiality Notice: This email is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law.  If you have received this message in error, please inform us promptly by reply e-mail, then delete the e-mail, and destroy any printed copy.  Thank you for your cooperation.

[Neil Fraser]

No, goog.Object is part of the Closure library.  That's unrelated to Blockly.

Blockly doesn't have an object-oriented scheme out of the box.  But perhaps someone else has experience building this?

Neil Fraser
https://neil.fraser.name

[Mark Friedman]

We've implemented some JavaScript object support for Blockly in our Thunkable iOS/✕ product.  The core of it can be seen in this gist.  Feel free to use it as you wish.  No guarantees of quality, completeness or usefulness for your purpose.  That said, feel free to ask questions and I'll try to help out as time allows.

-Mark

On Mon, Apr 23, 2018 at 4:04 PM, <rbu...@nfbconsulting.com> wrote:

--

[Bart Butenaers]

Hi Mark,

Really appreciate that you have shared your Javascript blocks with the community!

I have not fully tested the blocks yet, since I'm still struggling with the Blockly basics yet ...

Below two minor issues that I came across.  Will post them here, since I cannot create issues in your gist.

Issue 1 - Blockly declaration

I'm loading the Blockly javascript files before I'm loading your two files:

<script>
    [
      "/blocky/js/blockly_compressed.js",
      "/blocky/js/msg/messages.js",
      "/blocky/js/blocks_compressed.js",
      "/blocky/js/javascript_compressed.js",
      "/blocky/js/msg/js/en.js",
      "/blocky/js/toolbox/objectBlocksCodeGen.js",
      "/blocky/js/toolbox/objectBlocksDefs.js"
    ].forEach(function(src) {
      var script = document.createElement('script');
      script.src = src;
      script.async = false;
      document.head.appendChild(script);
    });
</script>

When I remove the first line (both in objectBlocksCodeGen.js and objectBlocksDefs.js), then everything seems to be working fine...

Issue 2 - code generation failure

All blocks are nicely displayed in the toolbox:

However when I use the 'property name' block, the code generation fails:

Could it be that the objectBlocksCodeGen.js in your gist is not complete ?  I don't find in that file a block for 'object_field' and 'object_create_mutator_top'.

Hope you can find some time to fix this.

Thanks !!

Bart

[Mark Friedman]

Bart,

  For issue #1, depending on how you are loading Blockly, you may or may not need those initial 'const Blockly = window.Blockly;' lines.  Obviously, you did not.  I have added a comment to the gist indicating that.

  For issue #2, the 'property name' block and the 'create object' block without the mutator (i.e. the last too blocks shown below in your toolbox) should not be in your Toolbox.  They are used within the mutator of the 'create object' block and are not meant to be stand-alone blocks.

  Hope this helps.

-Mark

--

[Bart Butenaers]

Hi Mark,

Hope you had a nice holiday.

About issue 1: Ok, didn't notice that.  Will remove them from my toolbox.

About issue 2: Perhaps you can make the code conditionally?  Something like this:

if (typeof Blockly === 'undefined') {
    const Blockly = window.Blockly;
}

By the way, your set of blocks works like a charm for my use case!  I need it all over the place.

Bart

[Mark Friedman]

On Wed, Jul 11, 2018 at 2:37 PM, Bart Butenaers <bart.bu...@gmail.com> wrote:

Hi Mark,

Hope you had a nice holiday.

About issue 1: Ok, didn't notice that.  Will remove them from my toolbox.

It wasn't obvious from the code ;-) 

About issue 2: Perhaps you can make the code conditionally?  Something like this:

if (typeof Blockly === 'undefined') {
    const Blockly = window.Blockly;
}

By the way, your set of blocks works like a charm for my use case!  I need it all over the place.

Great to hear!

-Mark

[Bart Butenaers]

Hi Mark,

I got a request from a user that wants to specify the property name dynamically.

So I did a few small updates to your blocks to accomplish this:

But I want to avoid to have my custom version of your blocks, in case you would ever update your version on gist...

So a few questions:

• Is this a good idea, or do you think it is more difficult to understand for a user ?
• Do you have a better proposal?
• Is there any chance you might update your blocks on gist?  Because I suppose it would become an problem for existing workspaces...
• Or is there a possibility to add two new blocks to your gist?  I could add the two new blocks to my toolbox, while others can choose to add the existing two blocks to their toolbox.

Thanks for your input!!

Bart

[Mark Friedman]

On Tue, Jul 24, 2018 at 12:16 PM, Bart Butenaers <bart.bu...@gmail.com> wrote:

Hi Mark,

I got a request from a user that wants to specify the property name dynamically.

So I did a few small updates to your blocks to accomplish this:

But I want to avoid to have my custom version of your blocks, in case you would ever update your version on gist...

I wouldn't worry about staying consistent with the gist.  To my mind, it's sort of the nature of a gist that users will adapt it for their needs.  If it were in a GitHub repo I would be more concerned.

So a few questions:

• Is this a good idea, or do you think it is more difficult to understand for a user ?

I think it's perfectly reasonable. 

• Do you have a better proposal?

I might consider generating a shadow block in the `get property` slot.  They're a nice compromise for this sort of thing, although sometimes beginners don't realize that the shadow blocks can be replaced.

• Is there any chance you might update your blocks on gist?  Because I suppose it would become an problem for existing workspaces...
• Or is there a possibility to add two new blocks to your gist?  I could add the two new blocks to my toolbox, while others can choose to add the existing two blocks to their toolbox.

I might update it to use shadow blocks, but probably not all that soon.

-Mark

 

Thanks for your input!!

Bart

--

[Bart Butenaers]

Mark,

The shadow blocks is indeed a user-friendly addition.  Just what I needed.  Thanks for the tip!!!!

Everything seems to be working fine now, in the updated version of your gist library:

But now I'm a little bit confused that it works fine, since there is some (mutator related) code that I haven't changed:

fieldBlock.setFieldValue(this.fields[i], 'field_name');

Do I need to change those lines also?  Because 'field_name' is now no value input anymore...

P.S. Below all code that I have touched from your gist, in case somebody would ever need it:

• I have removed the original %2 since I have removed a dummy input for both blocks:

    object_get_json: "get property %1 of object %2",
    object_set_json: "set property %1 of object %2 to %3",

• I have remove a dummy input on both nodes (to remove the empty line) and changed the type to 'input_type' and added a 'String' check and disable inline inputs:
  

const objectGetBlockDef = {
    "type": "object_get",
    "message0": getMessage('object_get_json'),
    "args0": [
      {
        "type": "input_value",
        "name": "field_name",
        "check": "String",
        "align": "RIGHT"
      },
      {
        "type": "input_value",
        "name": "object",
        "check": "Object",
        "align": "RIGHT"
      }
    ],
    "inputsInline": false,
    "output": null,
    "colour": CUSTOM_OBJECT_BLOCK_COLOR,
    "tooltip": getMessage('object_get_json_tooltip'),
    "helpUrl": ""
};

const objectSetBlockDef =  {
  "type": "object_set",
  "message0": getMessage('object_set_json'),
  "args0": [
    {
      "type": "input_value", // Gewijzigd
      "name": "field_name",
      "check": "String",
      "align": "RIGHT"
    },
    {
      "type": "input_value",
      "name": "object_field",
      "check": "Object",
      "align": "RIGHT"
    },
    {
      "type": "input_value",
      "name": "value_field",
      "align": "RIGHT"
    }
  ],
  "inputsInline": false,
  "previousStatement": null,
  "nextStatement": null,
  "colour": CUSTOM_OBJECT_BLOCK_COLOR,
  "tooltip": getMessage('object_set_json_tooltip'),
  "helpUrl": ""
};

• I changed the generators to get the field_name from the next block:

Blockly.JavaScript['object_get'] = function(block) {
  const value_field_name = Blockly.JavaScript.valueToCode(block, 'field_name', Blockly.JavaScript.ORDER_ATOMIC) || '\'\'';
  const value_object = Blockly.JavaScript.valueToCode(block, 'object', Blockly.JavaScript.ORDER_ATOMIC);
  const code = `${value_object}[${value_field_name}]`;
  return [code, Blockly.JavaScript.ORDER_NONE];
};

Blockly.JavaScript['object_set'] = function(block) {
  const value_field_name = Blockly.JavaScript.valueToCode(block, 'field_name', Blockly.JavaScript.ORDER_ATOMIC) || '\'\''; /
  const value_object_field = Blockly.JavaScript.valueToCode(block, 'object_field', Blockly.JavaScript.ORDER_ATOMIC);
  const value_value_field = Blockly.JavaScript.valueToCode(block, 'value_field', Blockly.JavaScript.ORDER_ATOMIC);
  return `${value_object_field}[${value_field_name}] = ${value_value_field};\n`;
};

[Mark Friedman]

On Wed, Jul 25, 2018 at 1:06 PM, Bart Butenaers <bart.bu...@gmail.com> wrote:

Mark,

The shadow blocks is indeed a user-friendly addition.  Just what I needed.  Thanks for the tip!!!!

Everything seems to be working fine now, in the updated version of your gist library:

But now I'm a little bit confused that it works fine, since there is some (mutator related) code that I haven't changed:

fieldBlock.setFieldValue(this.fields[i], 'field_name');

Do I need to change those lines also?  Because 'field_name' is now no value input anymore...

Those lines are used by the mutator for the `create object` block, so it is unaffected by the changes that you made to the  `get property` and `set property` blocks.

-Mark

[Bart Butenaers]

Ok, that is good new ;-)

Remark: my version of your blocks can be found in my node-red-contrib-blockly repository.