Switch to Python 3.14 and bump Reflex to latest release#348
Conversation
|
@Andrewtuebingen There are lots of pyright issues now (I guess due to some changes in reflex), which don't really seem solvable in a way other than putting lots of |
Andrewtuebingen
left a comment
There was a problem hiding this comment.
I played around and found 2 glitches.
First one in All Lectures when pressing on an arrow pointing sideways next to lecture name to view more information. For some reason, the arrow points south like it should but no information appear.
second Problem is going to manage prompts, I get this: [Reflex Frontend Exception]
Assertion: Unexpected value `` for children prop, expected `string`
AssertionError@http://localhost:3000/node_modules/.vite/deps/development-BnkBf4qi.js:22:8
assert@http://localhost:3000/node_modules/.vite/deps/development-BnkBf4qi.js:93:82
unreachable@http://localhost:3000/node_modules/.vite/deps/development-BnkBf4qi.js:74:8
createFile@http://localhost:3000/node_modules/.vite/deps/react-markdown.js:13621:18
Markdown@http://localhost:3000/node_modules/.vite/deps/react-markdown.js:13529:25
react_stack_bottom_frame@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:12868:21
renderWithHooks@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:4213:37
updateFunctionComponent@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:5569:31
runWithFiberInDEV@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:851:131
performUnitOfWork@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:8429:109
workLoopSync@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:8325:54
renderRootSync@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:8309:18
performWorkOnRoot@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:7994:41
performWorkOnRootViaSchedulerTask@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:9059:21
performWorkUntilDeadline@http://localhost:3000/node_modules/.vite/deps/react-dom_client.js:36:46
I agree that many of the current Pyright errors look like Reflex typing friction rather than meaningful code issues. However, I would prefer not to remove Pyright completely. It is still useful for state, database, and backend code. Is there a way to lower Pyright strictness? worst case I can go through the errors and comment them out or resolve them.
|
Regarding pyright: If you want to keep it, then let's do that. I'll add the necessary ignore comments. |
|
The error on the prompts page was the same issue with rx.markdown. This is a bug in Reflex. I reported it yesterday and they already merged a fix (reflex-dev/reflex#6531), so I suggest that we simply wait for the next release before merging this PR. I couldn't reproduce the issue on the "all lectures" page. For me the unfolding works as expected. |
The latest Reflex release (0.9.3) fixes an issue with `rx.markdown` components, which we had after the previous upgrade.
This is new in Reflex 0.9.3. From the release notes: > Projects should commit the new reflex.lock directory which includes > package.json and bun.lock. This helps avoid accidentally introducing > upstream changes and helps protect against supply chain attacks.
|
@Andrewtuebingen The fix in Reflex was released. I updated this branch and it is working for me now. Could you do a quick test as well? Regarding pyright: They are actually working on a fix for that as well, see reflex-dev/reflex#6545. Not sure, if we should wait for it, though, I think I'll rather add the "type: ignore" comments on an interim basis, so we can get this PR merged. |
Since a recent release, pyright does not accept `rx.cond` for an argument that expects a literal value. This will hopefully be fixed soon (see reflex-dev/reflex#6538), but for the time being, just add `type: ignore` comments, so we don't get false alerts from pyright.
|
I added the "type: ignore" comments now. |
I tested a bit and everything seemed to work as before to me but would probably be good if you could also play around a bit before we merge.
Closes #255