Static values for ``





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}






up vote
5
down vote

favorite
1












I've got a working datatable using the following in my component markup:



<lightning:datatable columns="{!v.columns}" data="{!v.configuration.channels}" keyField="channelId"/>


Columns is a List attribute:



<aura:attribute name="columns" type="List"/>


And is being set via the controller:



component.set("v.columns", [{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]);


And all is right with the world. Except for the verbosity. As usual with Lightning I find myself needing to write more code than should really be required. I was originally trying to do the columns like this:



<lightning:datatable
columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
data="{!v.configuration.channels}"
keyField="channelId"/>


But this wasn't working. I know that attribute binding is done at the Java level of the platform, but is there a way to simplify the working setup so that it doens't require extra code in the controller and an extra attribute that's not used for anything else?










share|improve this question




























    up vote
    5
    down vote

    favorite
    1












    I've got a working datatable using the following in my component markup:



    <lightning:datatable columns="{!v.columns}" data="{!v.configuration.channels}" keyField="channelId"/>


    Columns is a List attribute:



    <aura:attribute name="columns" type="List"/>


    And is being set via the controller:



    component.set("v.columns", [{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]);


    And all is right with the world. Except for the verbosity. As usual with Lightning I find myself needing to write more code than should really be required. I was originally trying to do the columns like this:



    <lightning:datatable
    columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
    data="{!v.configuration.channels}"
    keyField="channelId"/>


    But this wasn't working. I know that attribute binding is done at the Java level of the platform, but is there a way to simplify the working setup so that it doens't require extra code in the controller and an extra attribute that's not used for anything else?










    share|improve this question
























      up vote
      5
      down vote

      favorite
      1









      up vote
      5
      down vote

      favorite
      1






      1





      I've got a working datatable using the following in my component markup:



      <lightning:datatable columns="{!v.columns}" data="{!v.configuration.channels}" keyField="channelId"/>


      Columns is a List attribute:



      <aura:attribute name="columns" type="List"/>


      And is being set via the controller:



      component.set("v.columns", [{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]);


      And all is right with the world. Except for the verbosity. As usual with Lightning I find myself needing to write more code than should really be required. I was originally trying to do the columns like this:



      <lightning:datatable
      columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
      data="{!v.configuration.channels}"
      keyField="channelId"/>


      But this wasn't working. I know that attribute binding is done at the Java level of the platform, but is there a way to simplify the working setup so that it doens't require extra code in the controller and an extra attribute that's not used for anything else?










      share|improve this question













      I've got a working datatable using the following in my component markup:



      <lightning:datatable columns="{!v.columns}" data="{!v.configuration.channels}" keyField="channelId"/>


      Columns is a List attribute:



      <aura:attribute name="columns" type="List"/>


      And is being set via the controller:



      component.set("v.columns", [{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]);


      And all is right with the world. Except for the verbosity. As usual with Lightning I find myself needing to write more code than should really be required. I was originally trying to do the columns like this:



      <lightning:datatable
      columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
      data="{!v.configuration.channels}"
      keyField="channelId"/>


      But this wasn't working. I know that attribute binding is done at the Java level of the platform, but is there a way to simplify the working setup so that it doens't require extra code in the controller and an extra attribute that's not used for anything else?







      lightning lightning-datatable






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 26 at 6:53









      Matt Lacey

      20.7k546118




      20.7k546118






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          5
          down vote













          Short Answer



          No.



          Long Answer



          I'm not going to spend a ton of time on this, but the general idea is that each component gets to decide how to parse its attributes.



          As a working example, this code outputs what you expect:



          <aura:iteration items="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]" var="item">
          {!item.label}: {!item.fieldName}<br />
          </aura:iteration>


          I tried to figure out where the source for this goes off to, but it's buried deep in the Aura framework, and I don't have the inclination to try and find it, since it could take me hours. The point is, the items attribute parses its data into a native JavaScript list object automatically, if necessary. Most "aura" components do this naturally, unless explicitly noted otherwise.



          However, lightning:datatable does no such attribute parsing. The important section of code relevant to this question/answer is this setter method:



          set columns(value) {
          this._columns = Array.isArray(value) ? value : ;
          this.updateColumns(this._columns);
          }


          As you can see, it sets a private member variable (_columns) to the incoming value only if its already an array. It does not attempt to convert the value in to an array if it is not already one. So, the inline expression statement literally comes in as a string value, Array.isArray decides that a String is not an Array (because it is not one), and thus _columns ends up being an empty Array.



          So, in conclusion... yes, you can use static inline expressions sometimes. Feel free to try it on every attribute you care to test with. Some will work, others will not. If it doesn't, odds are it wasn't meant to. If you enable Lightning Debug Mode, you can dig deeper into the source and find out why, if you're really curious.



          Just remember that each component is free to choose how it handles its attributes, so you cannot make any general assumptions about how other components or attributes work. This is an unfortunate limitation of the platform. Most components are designed to work in a consistent manner with others that have similar attributes, but there is no obligation to do so, and some components just don't work right in certain configurations.





          If you're willing to put the one-time investment into it, you can take advantage of automatic expression parsing using your own wrapper component. The following code, for example, does render correctly:



          <aura:component >
          <aura:attribute name="columns" type="List" />
          <aura:attribute name="data" type="List" />
          <aura:attribute name="keyField" type="String" />

          <lightning:datatable
          columns="{!v.columns}"
          data="{!v.data}"
          keyField="{!v.keyField}"/>
          </aura:component>




          <c:lightningDataTableWrapper
          columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
          data="{!v.configuration.channels}"
          keyfield="channelId"/>




          Basically, for every attribute you want to support, you'd have to add it to your wrapper component. You'll have to decide if the wrapper class is worth the cost of static attribute support.






          share|improve this answer



















          • 1




            Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
            – Matt Lacey
            Nov 26 at 23:47











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "459"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f240472%2fstatic-values-for-lightningdatatable%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          5
          down vote













          Short Answer



          No.



          Long Answer



          I'm not going to spend a ton of time on this, but the general idea is that each component gets to decide how to parse its attributes.



          As a working example, this code outputs what you expect:



          <aura:iteration items="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]" var="item">
          {!item.label}: {!item.fieldName}<br />
          </aura:iteration>


          I tried to figure out where the source for this goes off to, but it's buried deep in the Aura framework, and I don't have the inclination to try and find it, since it could take me hours. The point is, the items attribute parses its data into a native JavaScript list object automatically, if necessary. Most "aura" components do this naturally, unless explicitly noted otherwise.



          However, lightning:datatable does no such attribute parsing. The important section of code relevant to this question/answer is this setter method:



          set columns(value) {
          this._columns = Array.isArray(value) ? value : ;
          this.updateColumns(this._columns);
          }


          As you can see, it sets a private member variable (_columns) to the incoming value only if its already an array. It does not attempt to convert the value in to an array if it is not already one. So, the inline expression statement literally comes in as a string value, Array.isArray decides that a String is not an Array (because it is not one), and thus _columns ends up being an empty Array.



          So, in conclusion... yes, you can use static inline expressions sometimes. Feel free to try it on every attribute you care to test with. Some will work, others will not. If it doesn't, odds are it wasn't meant to. If you enable Lightning Debug Mode, you can dig deeper into the source and find out why, if you're really curious.



          Just remember that each component is free to choose how it handles its attributes, so you cannot make any general assumptions about how other components or attributes work. This is an unfortunate limitation of the platform. Most components are designed to work in a consistent manner with others that have similar attributes, but there is no obligation to do so, and some components just don't work right in certain configurations.





          If you're willing to put the one-time investment into it, you can take advantage of automatic expression parsing using your own wrapper component. The following code, for example, does render correctly:



          <aura:component >
          <aura:attribute name="columns" type="List" />
          <aura:attribute name="data" type="List" />
          <aura:attribute name="keyField" type="String" />

          <lightning:datatable
          columns="{!v.columns}"
          data="{!v.data}"
          keyField="{!v.keyField}"/>
          </aura:component>




          <c:lightningDataTableWrapper
          columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
          data="{!v.configuration.channels}"
          keyfield="channelId"/>




          Basically, for every attribute you want to support, you'd have to add it to your wrapper component. You'll have to decide if the wrapper class is worth the cost of static attribute support.






          share|improve this answer



















          • 1




            Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
            – Matt Lacey
            Nov 26 at 23:47















          up vote
          5
          down vote













          Short Answer



          No.



          Long Answer



          I'm not going to spend a ton of time on this, but the general idea is that each component gets to decide how to parse its attributes.



          As a working example, this code outputs what you expect:



          <aura:iteration items="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]" var="item">
          {!item.label}: {!item.fieldName}<br />
          </aura:iteration>


          I tried to figure out where the source for this goes off to, but it's buried deep in the Aura framework, and I don't have the inclination to try and find it, since it could take me hours. The point is, the items attribute parses its data into a native JavaScript list object automatically, if necessary. Most "aura" components do this naturally, unless explicitly noted otherwise.



          However, lightning:datatable does no such attribute parsing. The important section of code relevant to this question/answer is this setter method:



          set columns(value) {
          this._columns = Array.isArray(value) ? value : ;
          this.updateColumns(this._columns);
          }


          As you can see, it sets a private member variable (_columns) to the incoming value only if its already an array. It does not attempt to convert the value in to an array if it is not already one. So, the inline expression statement literally comes in as a string value, Array.isArray decides that a String is not an Array (because it is not one), and thus _columns ends up being an empty Array.



          So, in conclusion... yes, you can use static inline expressions sometimes. Feel free to try it on every attribute you care to test with. Some will work, others will not. If it doesn't, odds are it wasn't meant to. If you enable Lightning Debug Mode, you can dig deeper into the source and find out why, if you're really curious.



          Just remember that each component is free to choose how it handles its attributes, so you cannot make any general assumptions about how other components or attributes work. This is an unfortunate limitation of the platform. Most components are designed to work in a consistent manner with others that have similar attributes, but there is no obligation to do so, and some components just don't work right in certain configurations.





          If you're willing to put the one-time investment into it, you can take advantage of automatic expression parsing using your own wrapper component. The following code, for example, does render correctly:



          <aura:component >
          <aura:attribute name="columns" type="List" />
          <aura:attribute name="data" type="List" />
          <aura:attribute name="keyField" type="String" />

          <lightning:datatable
          columns="{!v.columns}"
          data="{!v.data}"
          keyField="{!v.keyField}"/>
          </aura:component>




          <c:lightningDataTableWrapper
          columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
          data="{!v.configuration.channels}"
          keyfield="channelId"/>




          Basically, for every attribute you want to support, you'd have to add it to your wrapper component. You'll have to decide if the wrapper class is worth the cost of static attribute support.






          share|improve this answer



















          • 1




            Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
            – Matt Lacey
            Nov 26 at 23:47













          up vote
          5
          down vote










          up vote
          5
          down vote









          Short Answer



          No.



          Long Answer



          I'm not going to spend a ton of time on this, but the general idea is that each component gets to decide how to parse its attributes.



          As a working example, this code outputs what you expect:



          <aura:iteration items="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]" var="item">
          {!item.label}: {!item.fieldName}<br />
          </aura:iteration>


          I tried to figure out where the source for this goes off to, but it's buried deep in the Aura framework, and I don't have the inclination to try and find it, since it could take me hours. The point is, the items attribute parses its data into a native JavaScript list object automatically, if necessary. Most "aura" components do this naturally, unless explicitly noted otherwise.



          However, lightning:datatable does no such attribute parsing. The important section of code relevant to this question/answer is this setter method:



          set columns(value) {
          this._columns = Array.isArray(value) ? value : ;
          this.updateColumns(this._columns);
          }


          As you can see, it sets a private member variable (_columns) to the incoming value only if its already an array. It does not attempt to convert the value in to an array if it is not already one. So, the inline expression statement literally comes in as a string value, Array.isArray decides that a String is not an Array (because it is not one), and thus _columns ends up being an empty Array.



          So, in conclusion... yes, you can use static inline expressions sometimes. Feel free to try it on every attribute you care to test with. Some will work, others will not. If it doesn't, odds are it wasn't meant to. If you enable Lightning Debug Mode, you can dig deeper into the source and find out why, if you're really curious.



          Just remember that each component is free to choose how it handles its attributes, so you cannot make any general assumptions about how other components or attributes work. This is an unfortunate limitation of the platform. Most components are designed to work in a consistent manner with others that have similar attributes, but there is no obligation to do so, and some components just don't work right in certain configurations.





          If you're willing to put the one-time investment into it, you can take advantage of automatic expression parsing using your own wrapper component. The following code, for example, does render correctly:



          <aura:component >
          <aura:attribute name="columns" type="List" />
          <aura:attribute name="data" type="List" />
          <aura:attribute name="keyField" type="String" />

          <lightning:datatable
          columns="{!v.columns}"
          data="{!v.data}"
          keyField="{!v.keyField}"/>
          </aura:component>




          <c:lightningDataTableWrapper
          columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
          data="{!v.configuration.channels}"
          keyfield="channelId"/>




          Basically, for every attribute you want to support, you'd have to add it to your wrapper component. You'll have to decide if the wrapper class is worth the cost of static attribute support.






          share|improve this answer














          Short Answer



          No.



          Long Answer



          I'm not going to spend a ton of time on this, but the general idea is that each component gets to decide how to parse its attributes.



          As a working example, this code outputs what you expect:



          <aura:iteration items="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]" var="item">
          {!item.label}: {!item.fieldName}<br />
          </aura:iteration>


          I tried to figure out where the source for this goes off to, but it's buried deep in the Aura framework, and I don't have the inclination to try and find it, since it could take me hours. The point is, the items attribute parses its data into a native JavaScript list object automatically, if necessary. Most "aura" components do this naturally, unless explicitly noted otherwise.



          However, lightning:datatable does no such attribute parsing. The important section of code relevant to this question/answer is this setter method:



          set columns(value) {
          this._columns = Array.isArray(value) ? value : ;
          this.updateColumns(this._columns);
          }


          As you can see, it sets a private member variable (_columns) to the incoming value only if its already an array. It does not attempt to convert the value in to an array if it is not already one. So, the inline expression statement literally comes in as a string value, Array.isArray decides that a String is not an Array (because it is not one), and thus _columns ends up being an empty Array.



          So, in conclusion... yes, you can use static inline expressions sometimes. Feel free to try it on every attribute you care to test with. Some will work, others will not. If it doesn't, odds are it wasn't meant to. If you enable Lightning Debug Mode, you can dig deeper into the source and find out why, if you're really curious.



          Just remember that each component is free to choose how it handles its attributes, so you cannot make any general assumptions about how other components or attributes work. This is an unfortunate limitation of the platform. Most components are designed to work in a consistent manner with others that have similar attributes, but there is no obligation to do so, and some components just don't work right in certain configurations.





          If you're willing to put the one-time investment into it, you can take advantage of automatic expression parsing using your own wrapper component. The following code, for example, does render correctly:



          <aura:component >
          <aura:attribute name="columns" type="List" />
          <aura:attribute name="data" type="List" />
          <aura:attribute name="keyField" type="String" />

          <lightning:datatable
          columns="{!v.columns}"
          data="{!v.data}"
          keyField="{!v.keyField}"/>
          </aura:component>




          <c:lightningDataTableWrapper
          columns="[{label: 'Type', fieldName: 'type'}, {label: 'ID', fieldName: 'channelId'}]"
          data="{!v.configuration.channels}"
          keyfield="channelId"/>




          Basically, for every attribute you want to support, you'd have to add it to your wrapper component. You'll have to decide if the wrapper class is worth the cost of static attribute support.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 26 at 8:54

























          answered Nov 26 at 8:38









          sfdcfox

          242k10184410




          242k10184410








          • 1




            Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
            – Matt Lacey
            Nov 26 at 23:47














          • 1




            Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
            – Matt Lacey
            Nov 26 at 23:47








          1




          1




          Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
          – Matt Lacey
          Nov 26 at 23:47




          Accepted the answer on my phone (so didn't comment at the time).. for some reason it'd never occured to me that I could dig down very far into the component source. I'm behind the curve with Lightning and only just getting up to speed properly, but still finding it rather overcomplicated compared to other (granted, non-enterprise) frameworks. Thanks as always man.
          – Matt Lacey
          Nov 26 at 23:47


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Salesforce Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f240472%2fstatic-values-for-lightningdatatable%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Aardman Animations

          Are they similar matrix

          “minimization” problem in Euclidean space related to orthonormal basis