Conversation
… fix, I dont think it should be the same with Input
…ed to add more info for teacher mode and find ways to test backend connect, schema may need fix as JSON.stringfy can walk pass the zod schema check
refactor: Cytoscape
fix: remove debugging logs
…ity in FSA component
feat: implement GraphQL data fetching and add live preview functional…
revert: before preview
… and corrected data logic for sending response and answer to backend
Key features:
All changes done within Code structure
|
m-messer
left a comment
There was a problem hiding this comment.
Thanks for your work on this! Some minor comments, mainly on refactoring a style.
How much of this code is duplicated in FSA? Might it be worth commenting on those files?
There was a problem hiding this comment.
This is the wrong Md file.
yes absolutely, I wrote this when doing FSA, and it was copied to Graph and ignored, I'll fix this in the following commits
There was a problem hiding this comment.
Should this be ignored or just not added to the commit? (Do we want to ignore these in the future?)
There was a problem hiding this comment.
I think this is here by accident, FSA and PropositionalLogic never existed in this repo, will definitely fix this
There was a problem hiding this comment.
Oops, this was done by me, I had an issue with my laptop where I couldn't open more than 1 vscode open at the same time, but I wanted to see the code for PL config panel and FSA graph to take inspiration for Graph. Fixed now.
| 'ESSAY', | ||
| 'CODE', | ||
| 'MILKDOWN', | ||
| 'LIKERT', |
There was a problem hiding this comment.
Why remove these? If removed also remove the imports?
| } | ||
|
|
||
| class VoidResponseAreaTub extends ResponseAreaTub { | ||
| // public readonly responseType = 'VOID' |
| import { Graph, SimpleGraph } from './type' | ||
|
|
||
| // BackendGraph type: what backend expects | ||
| export interface BackendGraph { |
There was a problem hiding this comment.
Maybe add some explaination of why this is needed here.
| directed: provided.directed ?? false, | ||
| weighted: provided.weighted ?? false, | ||
| multigraph: provided.multigraph ?? false, | ||
| evaluation_type: Array.isArray(legacyEval) |
There was a problem hiding this comment.
Instead of multiline tenary, use if/else?
There was a problem hiding this comment.
I think tenary for directed weighted and multigraph makes it easier to read, if you believe it is better to use if/else we can change it to that.
There was a problem hiding this comment.
I may have put the comment on the wrong line here. I think there was a tenary that was formatted across multiple lines. Here it is fine.
| import { Graph, Node, Edge, GraphFeedback, CheckPhase } from './type' | ||
|
|
||
| /* ----------------------------- Local Styles ----------------------------- */ | ||
| export const useLocalStyles = makeStyles()((theme) => ({ |
There was a problem hiding this comment.
Should these style not be in the styles file or somewhere similar?
| const cy: Core = cytoscape({ | ||
| container: containerRef.current, | ||
| layout: { name: 'preset' }, | ||
| style: [ |
There was a problem hiding this comment.
Should these styles be in a style file or similar?
| return ( | ||
| <div style={{ display: 'flex', flexDirection: 'column', gap: 12 }}> | ||
| <div | ||
| style={{ |
| "typescript": "^5.4.5", | ||
| "typescript-eslint": "^7.11.0", | ||
| "vite": "^7.0.0" | ||
| "vite": "^5.4.11" |
There was a problem hiding this comment.
Why to download a library? Could 7.0.0 be kept?
| multigraph: config.multigraph, | ||
| evaluation_type: config.evaluation_type, | ||
| } | ||
| console.log('[GraphTub] sending to backend:', flatAnswer) |
There was a problem hiding this comment.
Are you gonna keep the console.log ?
Many developers prefer to remove any console.log before merging.
| const isCircle = diameter > 20 && | ||
| strokeLength > circumference * 0.3 && | ||
| distance < diameter * 0.5 |
There was a problem hiding this comment.
These 3 constants should be defined as constants, even if local constants in this file.
| target: e.target().id(), | ||
| label: (e.data('label') as string) ?? '', | ||
| metadata: {}, | ||
| weight: 0 |
There was a problem hiding this comment.
Are you accepting weighted graphs? If so, should it preserve the original weight? Something like parseFloat(e.data('weight')) ...
There was a problem hiding this comment.
Weighted graphs are not currently accepted, none of the evaluation in the backend requires the graph to be weighted. However evaluation that requires weight could be an interesting thing to be implemented in the future, where the response area could easily allow weighted graphs to be made.
| static toSimple(graph: Graph): SimpleGraph { | ||
| return { | ||
| nodes: graph.nodes.map(n => `${n.id}|${n.label || ''}|${n.x || 0}|${n.y || 0}`), | ||
| edges: graph.edges.map(e => `${e.source}|${e.target}|${e.weight || 1}|${e.label || ''}`), | ||
| directed: graph.directed, | ||
| weighted: graph.weighted, | ||
| multigraph: graph.multigraph, | ||
| evaluation_type: [], | ||
| } | ||
| } |
There was a problem hiding this comment.
GraphConverter.toSimple() and GraphConverter.fromSimple() in utils.ts seems to do the same as toSimpleGraph() and fromSimpleGraph() in type.ts
Am I right? Should some refactoring make sense?
| // ----------------------------- | ||
| // Compressed Graph: JSON-stringified nodes/edges | ||
| // ----------------------------- | ||
| export const CompressedGraphSchema = z.object({ | ||
| nodes: z.array(z.string()), // JSON.stringify(nodes) | ||
| edges: z.array(z.string()), // JSON.stringify(edges) | ||
| directed: z.boolean().default(false), | ||
| weighted: z.boolean().default(false), | ||
| multigraph: z.boolean().default(false), | ||
| name: z.string().optional(), | ||
| metadata: z.record(z.any()).optional().default({}), | ||
| }); | ||
|
|
||
| export type CompressedGraph = z.infer<typeof CompressedGraphSchema> | ||
|
|
||
| // ----------------------------- | ||
| // Example: compress function | ||
| // ----------------------------- | ||
| export function compressGraph(graph: z.infer<typeof GraphSchema>) { | ||
| return { | ||
| ...graph, | ||
| nodes: JSON.stringify(graph.nodes), | ||
| edges: JSON.stringify(graph.edges), | ||
| }; | ||
| } | ||
|
|
There was a problem hiding this comment.
CompressedGraphSchema, CompressedGraph, and compressGraph are never imported or used anywhere in the codebase. Like the intentionally-unused files you mentioned in your PR description, if this is a future idea, please add a comment explaining why it exists. Otherwise, remove
Almost everything is copied from FSA, the only difference of graph and FSA is the feedback and the answer schema, which both use a temporary frontend-type to walk around the two-layer json requirement of the answer Therefore if needed, we can try to unify the type and make graph and FSA combined, however, in this assignment we probably wont have time to finish this (Given its near the end and the exams) |
Thanks for confirming! No need to merge before the deadlines, it's just good to know if/when we pull the changes into the application. |
Sorry for messing up with the branches, I'll try to migrate the PR content here