dom-change equivalent for iron-list about iron-list HOT 11 CLOSED

Can you give an example that will require you to do that processing?

from iron-list.

https://github.com/m4b/silicon-instructions

So I need to call highlight.js to get the prettified code. Specifically this observer for the instructions array:

    _newInstructions: function(instructions) {
      // add the highlighting into the instructions
      instructions.forEach(function(instr, index) {
        var res = hljs.highlightAuto(instr.mnemonic + ' ' + instr.op_str);
        instr.html = res.value; // this right here seems hackish
        instr.id = '_' + index; // so we can lookup the `<silicon-instruction>` easily
        instr.language = res.language;
      }, this);
    },

Then in silicon-instruction.html I check to see if there is an html element, meaning it was post-processed, and stuff that into the innerHTML. It all seems kind of hackish to me, dunno.

from iron-list.

hmm, what about creating an element and using data binding to provide the input to the custom element?

from iron-list.

ping

from iron-list.

oh hehe, did you want me to do something?

I'm not sure what the best approach is; whether to have a notification when it's done rendering the current viewport, or preprocessing the item list via an observer and inserting what you need there. I ended up sticking with the last and doing some other icky stuff for highlighting. The current implementation is:

    _newInstructions: function(instructions) {
      // add the highlighting into the instructions
      instructions.forEach(function(instr, index) {
        var res = hljs.highlightAuto(instr.mnemonic + ' ' + instr.op_str);
        instr.html = res.value;
        instr.id = '_' + index; // so we can lookup the `<silicon-instruction>` easily
        instr.language = res.language;
        instr.selected = ''; // more css hacks
      }, this);
    },

because now I need to do proper CSS highlighting, which is a combination of having a selected property inserted into the instruction and then using this.classFollows, which results in highlighting code like this:

    _select: function(i) {
      var siliconInstruction = this.$$('#_' + i);
      var currentSiliconInstruction = this.$$('.selected');
      var inst = this.instructions[i];
      var oldInst = this.selected;
      this.$.selector.select(inst);
      if (siliconInstruction === currentSiliconInstruction) {
        siliconInstruction = undefined;
      }
      if (currentSiliconInstruction){
        this.toggleClass('glow', false, currentSiliconInstruction);
      }
      // moar silly hacks
      inst.selected = this.glow ? 'selected glow' : 'selected';
      if (oldInst) {
        oldInst.selected = '';
      }
      // swaps selectedness
      this.classFollows('selected', siliconInstruction, currentSiliconInstruction);
      // need to remove glow in case we switched from glow/non-glow
      if (this.glow) this.classFollows('glow', siliconInstruction, currentSiliconInstruction);
    },

Which is kind of manual and crappy, but couldn't figure out any other way to get around the re-used state aspect.

So I actually checked, and in iOS for dealing with these issues, especially really fast scrolling, you make a call like:

UITableViewCell *cell = (id)[tableView cellForRowAtIndexPath:indexPath];
  if (cell){ // if the async request isn't fast enough, need to check if we're still onscreen
    cell.imageView.image = image;

So each cell (i.e., list item) has an index; but if the scroll happens before the next line executes, the cell is null. This is sort of what I do with if (currentSiliconInstruction).

So, the answer is, I'm not sure what's best; it seems like you're following the iOS approach where all state is stored with the item, and woe unto others if not. This does seem like the most maintainable; I just didn't like iterating over the array every change to stick in the extra state I needed due to performance considerations, since in my uses cases the instruction-list is going to change extremely rapidly, so every change will cause O(n) processing...

from iron-list.

what about if you have something like this:

<iron-list>
  <template>
    <highlighter instructions="[[item.instructions]]"></highlighter>
  </template>
</iron-list>

from iron-list.

Not sure what that is supposed to do, I'd have to see what highlighter does. The current behavior is visible here

from iron-list.

In my example <highlighter> is basically your <silicon-instruction>. I can see your point. Can you highlight each line independently of each other, or do you have to keep states. e.g. scopes, blocks, contexts, etc. ?

from iron-list.

So about half of the reason for this feature request was removed once you implemented the selection api (:thumbsup: btw), because I had to roll my own selector.

The other half is sort of still there, namely I need to preprocess each instruction. But calling the highlighter during every scroll/redisplay of new items would certainly be less performant than preprocessing once on new items, in almost every use case, so I'd feel fine closing this issue.

from iron-list.

ok I will consider this feature. We still have so many features to implement.

from iron-list.

keep up the good work! :)

from iron-list.