Repeat.for using range

Help Requests
1

Can someone point me in the right direction in how to pass a repeat.for range value into a binding on the element. Or an alternative (valueconverter?)

This works in creating the elements needed, but the two defined indexes i and j are not evaluated and passed as the raw text.

I tried i,j…$i,j...{i},{j}...{i},{$i}

Here is sample code and the binding is the cellModel.bind:

    <template repeat.for="i of 4">
        <template  repeat.for="j of 10">
            <cell class="matrixCell" cellModel.bind="cellRowCol[i][j]"></cell>
        </template> 
    </template>
2

Still haven’t figured out how to access those values inside a bind if any can help.

I also have the basic sudoku working. I wouldn’t call it finished or code beautiful, but it is functional.
It barely touches Aurelia 2’s capabilities.

3

I would create a 2D array in my viewModel, and populate it with cells data.
and then iterate over that arrays in your view, instead of just iterating over ints and then try to bind them to a structure.

4

You get so locked into thinking of one way of doing something the obvious staring in your face is missed. Thanks for the suggestion.

I am trying to rework my usage of the css grid for the matrix so that would/should be a great solution.

I still wonder how you might pass a range iterator value though. I would think it should work just like $index or $event does, but perhaps those are specifically handled cases.

5

I didn’t understand what you meant by range iterator.

I meant for you to do something like that.

cellRowCol: Cell[][] = ...;  //better rename this to cells - but I kept the name you already had

 <template repeat.for="row of cellRowCol">
    <template repeat.for="cell of row">
        <cell class="matrixCell" cellModel.bind="cell"></cell>
    </template> 
</template>

BTW: I assumed your cells were a 2D array, if they are a regular array, you can simplify the repeat.
also - would it help if you had a div for each row? (what if you need to style the rows etc…)

6

So my intent was to reduce the wall of html into a simple x,y loop over the array to create the grid cells in sudoku.html as you noted.

I have just done an update on the project with another version of the grid layout to remove all the original spacing divs I had to insert to get it to format right (3x3 blocks with dividers.)

The new css / html is much cleaner, but its not there yet as my current css grid setup is using a “cells pattern” where each cell of the 3x3 is populated with the sub-cells, whereas the data is in a row format (matrix[9][9]).

I still am working on trying to get it back to something that will still be easily maintainable, but readable using the loops.

Hopefully that makes sense.

So right now the issue is me wrapping my head around the css grid configurations (I wanted to use that to see how it works) and really has nothing to do with Aurelia proper.

7

But if you use a simple array, 1 dimension, the HTML should become even easier as a single loop should suffice. Using the $index you can place additional css classes with mod operations to get borders etc defined.

Alternatively store objects as cells, containing props indicating what type of cell they are and use them within a cell component which then by using that object info knows what to do, e.g border, placement etc. Here is a sample for the board game i was building

8

Everything you said is a valid approach.

I thought I had noted this on one of the threads where I was working on this, but appears to be somewhere else. This was an exercise using css grids, and to play with a very very simple AU2 project and part of my continued learning experience.

Everything after this is just blabbing opinion stuff and can be ignored if desired.

Please understand everything that follows is in no way demeaning that idea, or suggesting that it shouldn’t be used. This is just my own philosophy at the moment till I get convinced that there is a better way of doing things.

As with all programming there are many ways to solve problems, and each has its own positive and negative aspects. Then there is the execution of that solution, which can be done using a simpler concept and perhaps (more likely to be) verbose code, we have super tight and condensed code using a more creative and ‘elegant’ concept that the lords of coding drool over, and of course everything in between.

I believe there are places for both, but in general I will 90% of the time take the simpler approach over the more complex. So for example, have you ever done this? Created a super cool application, with some very creative coding, and the walked away from it for a few weeks to come back and have to re-figure out what it was you did and why you did it that way? Now, how about 6 months? A year? What about low-level or intermediate coders that will maintain that code. Sure creating tests help, but in the end you spend a lot of time relearning how that creative coding technique works again.

I jump between .Net, Java, Web programming, and sometimes don’t get back to the ‘other’ environments for weeks. Hence, I lean toward highly readable code for all levels.

That other 10% (I would even venture to say its less then 1% of the time) for performance you need to use those creative, but complicated to grasp coding techniques.

I like Aurelia because the framework can do what it needs to do in order to be performant, but the application layer can be written very simply without a lot of framework clutter, or the application developer having to be a master coder to either create, or maintain theirs or others applications.
There are still some gotcha’s with Aurelia, but that is mostly (at least on my part) over complicating what Aurelia has simplified because we have all learned how to write said overly complex code.

After learning a few key Aurelia specific concepts (DI, lifecycles, binding, observables) the rest is mostly just wading through the javascript/css menagerie of tools that feels like it changes weekly. There is always the new kid on the block that shows how bad the old kid on the block (from last week) is now bad and obsolete and everyone jumps on board.

Okay, with that wall of text out of the way… :roll_eyes:
I am going to look to see about setting up and using a single array. I have an idea on how I can maintain the readability, and ease of displaying and validating the cells, rows, cols. If I am successful, and do an update.

thank you @zewa666 @avrahamcool for your input, and I hope your future comments as well.

1 Like
9

So I was able to simplify the html, and I still think its clear what is happening using the grid-template-areas.

You can see it in the project code here shortly, but those those that want to short version here is the html and the css without changing the 2d-array to 1d for the moment or any other code changes.

    <div id="matrix" class="matrix-layout">
        <template repeat.for="row of matrix.cellRowCol">
            <template repeat.for="col of row" if.bind="$parent.index !== 0 && $index !== 0">                
                <cell class="cell-${$parent.$index}${$index}" cell-model.bind="col"></cell>        
            </template>
        </template>
    </div>

.matrix-layout {
    display: grid;
    padding: 4px;
    gap: 2px;
    grid-template-columns: repeat(3, 1fr) auto repeat(3, 1fr) auto repeat(3, 1fr);
    grid-template-rows: repeat(3, 1fr) auto repeat(3, 1fr) auto repeat(3, 1fr);
    grid-template-areas:
        "cell11 cell12 cell13 . cell14 cell15 cell16 . cell17 cell18 cell19"
        "cell21 cell22 cell23 . cell24 cell25 cell26 . cell27 cell28 cell29"
        "cell31 cell32 cell33 . cell34 cell35 cell36 . cell37 cell38 cell39"
        ". . . . . . . . . . ."
        "cell41 cell42 cell43 . cell44 cell45 cell46 . cell47 cell48 cell49"
        "cell51 cell52 cell53 . cell54 cell55 cell56 . cell57 cell58 cell59"
        "cell61 cell62 cell63 . cell64 cell65 cell66 . cell67 cell68 cell69"
        ". . . . . . . . . . ."
        "cell71 cell72 cell73 . cell74 cell75 cell76 . cell77 cell78 cell79"
        "cell81 cell82 cell83 . cell84 cell85 cell86 . cell87 cell88 cell89"
        "cell91 cell92 cell93 . cell94 cell95 cell96 . cell97 cell98 cell99";
    border: 1px solid lightslategrey;
    background-color: black;
}

@for $x from 1 through 9 {
    @for $y from 1 through 9 {
        .cell-#{$x}#{$y} {
            grid-area: cell#{$x}#{$y};
        }
    }
}
10

Yep sorry I didn’t get the whole convo. I also highly agree with your readability argument. Not sure if I’d agree on this exact scenario to match but I got the point. The 1d array wasn’t contradicting the css grid approach so I was unsure about the issue at first.

But I can see you found your way around the range issue.

11

@zewa666 Right, your skill level, and experience in Web Dev far out weights mine, and I appreciate that you took the time to response.

That is one of the things I like about the Aurelia team, they really want to help. And this, other then the syntax for looping isn’t even an Aurelia issue.

I have been coding for longer then I wish to admit (I know exactly why staggered braces were used…can you say 160k SS FD, and I still despise them today). I am opinionated, and have my own thoughts and ways of doing things, but I always, always try to learn, and change or shift those positions when I am shown a better way. Here there is no right or wrong way, more of the nuances of different patterns, techniques, and applied experience.

I would love to see your implementation as I learn by looking at code more then reading about it personally. That said, that is time most of you with all the work you are already doing, just don’t have the time for in 99% of the cases. I’d much rather the time be spent working on one of the best frameworks out there!!

Thanks again.

1 Like
12

So just in follow-up here, I did end up moving to a 1d array as suggested, and due to the puzzle generator I ended up using did also.

I also worked around my OP issue by using a value converter to create the css class variable I needed.
Again, Aurelia super simplified it.

        <template repeat.for="cell of sudoku">
            <cell class="cell-${$index | cellPosition}" cell-model.bind="cell"></cell>
        </template>

export class CellPositionValueConverter
{
    toView(value)
    {
        return (Math.floor(value/9) + 1 + "") + ((value % 9) + 1 + "");
    }
}
1 Like
13

Another milestone achieved! I got the GitHub page to work and the demo running on it.
I can hear the UI guys tsk tsking me already. Keyboard only, no touch, not responsive…lol

14

Nice work, there is definitely room for improvement and code cleanup but as you mentioned, it’s pretty easy to go straight into the code and follow along what is happening. Somehow the code also reminds me very heavily of an old university assignment I had to create a Sudoku for the console with C.

That said, it just always fascinates me how little framework-code one finds in typical Aurelia apps. Clearly the bulk of your work was business logic.

One question though, why did you nest cell inside a template that gets repeated. Couldn’t you place the repeat directly on the cell itself?

15

@zewa666 its left over from when it was a double loop for the 2d array and should be removed.
I’ll mark that as a todo. And thanks for the feedback.

As far as Aurelia, absolutely. You can hardly notice it. I spend more time generally fighting the tools, then I do Aurelia.

The only current nit I have with the new V2 isn’t the framework directly, but why the cli build command got rid of the creating a /dist deploy directory containing ALL the files to move to staging/production.

It now only contains the app and entry bundles at the root level of /dist.
I now have to modify the gulpfile.js to create a new /deploy directory, and copy the index.html and /dist into it so that I can for instance, deploy it to gh-pages.

Something (I think) you would routinely need for simple® CLI projects. For me at least, it just added another step I had to figure out when it was builtin before.

1 Like