Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 03 14:12
    drdreo opened #1573
  • Nov 14 22:14
    treshugart closed #1568
  • Nov 14 22:14
    treshugart commented #1568
  • Nov 06 22:23
    Jason-Cooke commented #1572
  • Nov 06 19:40

    treshugart on master

    docs: fix typo Merge pull request #1572 from J… (compare)

  • Nov 06 19:40
    treshugart closed #1572
  • Nov 06 19:40
    treshugart commented #1572
  • Nov 06 19:25
    now[bot] commented #1572
  • Nov 06 19:25
    now[bot] commented #1572
  • Nov 06 19:24
    now[bot] commented #1572
  • Nov 06 19:24
    now[bot] commented #1572
  • Nov 06 19:24
    Jason-Cooke opened #1572
  • Oct 27 10:52
    jogibear9988 opened #1571
  • Oct 13 04:43
    kimjs3550 edited #1570
  • Oct 13 04:40
    kimjs3550 opened #1570
  • Sep 04 16:35
    treshugart commented #1569
  • Sep 04 16:34
    treshugart commented #1568
  • Aug 27 13:16
    gseerden opened #1569
  • Aug 26 01:28
    akoushke opened #1568
  • Jul 21 11:09
    now[bot] commented #1567
Janne Siera
@jannesiera
I have a similar case where I'm trying to put a custom WC on a page while rendering a web forms page and want to try to hook up the callback to a web forms postback.
Alexandre Theodoro da Silva
@alexandrethsilva
@jannesiera yeah, in my case I'm trying to create a generic chart web component based on echarts, but the config for a number of the options should be able to accept functions for the library to use internally during the assembly of the charts
i have the benefit that i'd be using it only within other internal components of the application, so the much hated eval could possibly be my only salvation there, but still wanted to check whether there's any other possibility that i'm missing
but yeah, tricky..
Janne Siera
@jannesiera
@alexandrethsilva allow the requirements to set properties? Or are you forced to pass it as an attribute somehow?
Alexandre Theodoro da Silva
@alexandrethsilva
hey @jannesiera sorry for the delay, but yeah, i'm forced to pass it as attributes because of the generalised nature of it
the idea is basically to have a generic component that's gonna be consumed by other specialised components
e.g. a generic charts component that exposes the entire api of the underlying lib
then being consumed by a specialised chart that would then have knowledge of an api to pull the data from and pass on to this underlying one through the exposed tag attributes
not sure if i was able to express it clearly, but that's one of the ideas
Janne Siera
@jannesiera
@alexandrethsilva I understand. However, what is the reason for passing this as attributes (strings) instead of properties (can be anything, inlcuding functions)?
Alexandre Theodoro da Silva
@alexandrethsilva
@jannesiera i guess the way i'm seeing it is that the consumer will send it through linked attributes?... that's to say, that this generic component won't be available directly in the codebase but will be–to the consumer component–just a tag?
i might be missing something of what you're saying though... i feel like i am :smile:
let's say I have a chat component that looks like this, kinda:
class ChartComponent extends Component {
  static get is() {
    return "generic-chart"
  }

  static get props() {
    return {
      color: {
        attribute: true,
      },
      dataZoom: {
        attribute: true,
      },
      legend: {
        attribute: true,
      },
      series: {
        attribute: true,
      },
      ...
    }
  }

  renderCallback() {
    const {style, className} = this.props

    return h("div", false, [
      <ReactEcharts
        option={omit(["style", "className"], this.props)}
        style={style}
        className={className}
      />,
    ])
  }
}
then the consumer component, since it has no access to this component directly as a module, only creates a definition on it's on renderCallback() that would look like this, kinda:
Alexandre Theodoro da Silva
@alexandrethsilva
class SpecialisedChartComponent extends Component {
  static get is() {
    return "specialised-chart"
  }

  connectedCallback() {
    // MAKES API CALL
    // RETURNS SOME DATA
    // UPDATES ITS STORE
  }

  renderCallback() {
    return h("div", false, [
      <generic-chart
        series={dataObjectThatCouldContainFns}
        ...
      />,
    ])
  }
}
so, in that case i can only pass things as tag attributes really
or did i miss something?
Janne Siera
@jannesiera
As far as I understand SkateJS, it goes something like this:
```static get props() {
return {
  color: {
    attribute: true,
  },
  dataZoom: {
    attribute: true,
  },
  legend: {
    attribute: true,
  },
  series: {
    attribute: true,
  },
  ...
}
} ```
Those are your properties, which you are reflecting as attributes.
Alexandre Theodoro da Silva
@alexandrethsilva
right
Janne Siera
@jannesiera
I assume that means they are available both as properties and attributes
if SkateJS is smart as I think it is, when you pass a function to one of those properties, it will attempt to directly set the property
also, you don't need to specifically reflect properties as attributes
it's just like the 'regular' onclick event you find in your regular html

element.onclick = function() { console.log('Hello world'); }

vs

element.setAttribute("onclick", "return console.log('Hello world');")

does that make sense?
Alexandre Theodoro da Silva
@alexandrethsilva
ah I see what you're trying to say...
I think I see.
but then I'd have to do that imperatively instead of declaratively at the time of the tag definition right?
so I think that's one of my issues, because I wanted to have just the definition being rendered with the chart specs directly every time
Janne Siera
@jannesiera
okay, so if you want declarative syntax it becomes about the templating language
Alexandre Theodoro da Silva
@alexandrethsilva
but your solution would work too indeed if i'd go that way
Janne Siera
@jannesiera
I don't know what SkateJS uses exactly
how's it called, hyper-something?
Alexandre Theodoro da Silva
@alexandrethsilva
yeah, i think so
Janne Siera
@jannesiera
If you take JSX for example, it translates declarative syntax into imperative syntax
React for example will always set properties
I'm assuming this one will do the same, but I don't know
Alexandre Theodoro da Silva
@alexandrethsilva
oh really? that's interesting. didn't know it
'Note that hyperscript sets properties on the DOM element object'
there you go
Alexandre Theodoro da Silva
@alexandrethsilva
nice!
man, really nice convo. thanks a lot
Janne Siera
@jannesiera
No problem, it can be a bit confusing in the beginning
Alexandre Theodoro da Silva
@alexandrethsilva
i'll have a look at it and see if i untangle myself :smile:
Janne Siera
@jannesiera
basically if i were you:
Alexandre Theodoro da Silva
@alexandrethsilva
yeah, I guess the docs leave a few things in the air for the newcomers
i should probably make a contribution once i figure it out and maybe make it a bit more comprehensive over there
Janne Siera
@jannesiera
If the components are only for your 'own' use: Don't bother reflecting attributes. Just write your components, all 'attributes' you declaratively set on your components will be set as properties. Just go on and build your stuff.
Alexandre Theodoro da Silva
@alexandrethsilva
yeah, sounds like the way to go indeed