Table with nested for loop results in blank screen

[harderj]

Hello forum, from this n00b here.

As exercise I decided to write a sudoku solver UI with Dioxus. I am pretty sure that I am doing it wrong. However, instead of giving me an error, this seems to compile fine and then give me a blank white screen. Substitute grid.read()[i_][j_] with 0 and the blank screen (and functionality that I want) disappears. Maybe someone care to tell me a better way of achieving this.

#[component]
fn App() -> Element {
	rsx! {
		SudokuGrid {}
	}
}

const N: usize = 3;

#[component]
pub fn SudokuGrid() -> Element {
	let mut grid = use_signal(|| vec![vec![0i32; N]; N]);
	rsx! {
		table {
			for i in 0..N {
				for i_ in i*N..(i*N+N) {
					tr {
						for j in 0..N {
							for j_ in j*N..(j*N+N) {
								td {
									input {
										value: {
											grid.read()[i_][j_]
										},
										onchange: move |event| grid.write()[i_][j_] = event.value().parse::<i32>().unwrap_or(0)
									}
								}
							}
							td {}
						}
					}
				}
				tr { td {} }
			}
		}
	}
}

[ealmloff]

Do you see any errors in your console and are you using fullstack? If you are, it might be a hydration issues. The browser will insert a tbody element since you are missing one which can cause a mismatch between what the server rendered and what the client hydrates

[harderj]

No errors in the console - using verbose option. Not using fullstack. The only code I left out is this:

#[component]
fn App() -> Element {
	rsx! {
		SudokuGrid {}
	}
}

running using dx serve.
Can you reproduce it?

[harderj]

I am able to make my idea work like this:

#[component]
pub fn SudokuGrid() -> Element {
	let mut grid = use_signal(|| [0i32; N.pow(4)]);
	rsx! {
		table {
			for (i, num) in grid.read().iter().enumerate() {
				if i % (N * N) == 0 { tr {} }
				if i % (N * N * N) == 0 { tr { td{} } }
				if i % N == 0 { td {} }
				td {
					input {
						value: {
							*num
						},
						onchange: move |event| grid.write()[i] = event.value().parse::<i32>().unwrap_or(0)
					}
				}
			}
		}
	}
}

But I would say that it is a bit dissatisfactory, that one have to make workarounds like this, unless there is some clever reason why one should do this rather than my original approach. Either way I think there should be some kind of error to tell me why, rather than a blank screen.

[harderj]

I opened this as an issue instead: #4531