teacher tool: add address bar #9839

eanders-ms · 2024-01-31T15:52:35Z

Implements the address bar control.

TODO (in a future PR):

Swap arrow icon for a carriage return
Make the icon clickable

srietkerk · 2024-01-31T17:46:49Z

teachertool/src/components/AddressBar.tsx

+    className?: string;
+}
+
+export const AddressBar: React.FC<IProps> = ({ className }) => {


Is AddressBar the right name for this? I know that SearchBar isn't right, either, but when I read address bar, it took me a minute to understand that this is the component where the user submits the share link.

I chose AddressBar because:

it's modeled closely after a browser's address bar.

the most common input will be a pasted URL, like an address bar.

I am open to alternatives!

ShareLinkInput would be the most descriptive, probably. But I'm fine with AddressBar.

srietkerk · 2024-01-31T17:48:53Z

teachertool/src/components/AddressBar.tsx

+}
+
+export const AddressBar: React.FC<IProps> = ({ className }) => {
+    const { state: teacherTool } = useContext(AppStateContext);


Is there a reason we wouldn't just name this projectMetadata?

I believe this is a way of extracting projectMetadata from the teacherTool object.

I don't think I'm following. Naming this projectMetadata would mean accessing the actual project metadata like projectMetadata.projectMetadata.
Line 17 is where I extract projectMetadata to a local var.

Oh, yeah, I was confused because the projectMetadata variable was accessed similar to how this is, and I thought we could just rename the state, but I realize now that it is a similar accessor, but we need both of these. I know I did not explain that well, but long story short, I understand now and appreciate the clarification!

srietkerk · 2024-01-31T17:57:31Z

teachertool/src/components/ProjectWorkspace.tsx

+export const ProjectWorkspace: React.FC<IProps> = () => {
+    return (
+        <div className={classes(css, "panel", "h-full", "w-full", "flex", "flex-col")}>
+            <Toolbar toolbarClass={css["grow-1"]}>


I know this is a placeholder, but I was wondering if the project view toggle we're going to fill in here is something we'll be able to do in v1? Is the toggle just so a teacher can look at a student's project in JavaScript? Would it be clear that they can't validate projects in JavaScript?

They actually can still validate a project even after switching to JS. It'll still validate the blocks, but it should all still work. It won't work well if a project was made in Javascript instead of blocks, but I think that's a different scenario.

Yeah, I'm worried the toggle will give the impression that we support evaluating JavaScript-only projects, but this is an assumption. I imagine a scenario where a teacher sees the toggle, thinks "Oh, I can validate student projects in JavaScript, too", uploads a JavaScript-only project and then the evaluation doesn't work. But, if a teacher uploads a JavaScript project, that's something that we can know, right? And just error and tell the user "sorry, we cannot evaluate JavaScript-made projects at this time".

I wouldn't worry about it too much for v1, but yes I think we can check the preferred editor and error if needed.

I think there is value in having the toggle regardless, as one teacher did mention they like to switch to JS to search for things in the code, rather than scrolling through blocks, so there's a known use-case there.

Good point Sarah. I'd like to leave this as an open design question for now. I'll add it to the work board to track.

srietkerk · 2024-01-31T18:01:43Z

teachertool/src/components/SplitPane.tsx

 }

-export const SplitPane: React.FC<IProps> = ({ className, split, children }) => {
+export const SplitPane: React.FC<IProps> = ({ className, split, children, leftPaneClass, rightPaneClass }) => {


What will something like the left or right pane class look like?

The purpose is to enable the parent to inject css into the div that wraps the panel content. I may end up removing it. This can be accomplished without adding a prop.

srietkerk · 2024-01-31T18:04:09Z

teachertool/src/components/styling/RubricWorkspace.module.scss

Is it valuable to create a styling module for something that's empty right now?

It won't be empty for long.

srietkerk · 2024-01-31T18:12:45Z

teachertool/src/components/styling/shared.scss

+ * import this file directly into components. Instead, import into the
+ * component's module.scss file so that it will be scoped to that module.
+ *
+ * Classes in this file are composable, modeled after [Tailwind CSS](https://tailwindcss.com)


I know we chatted about this as we were getting started and decided not to use tailwind, so I just wanted to ask the benefit of creating a system like this ourselves? I know this can make things really clean, so do we want to make an in-house solution like tailwind so we can also use Sass modules? Do we want to use both systems because it's nice to have these pre-programmed standards while also having custom styling that is a bit easier to read?

I love tailwind's composable classes specifically for controlling flex layout. I was building my own set and it was starting to look a lot like tailwind, so I just copied this tiny subset from tailwind. It doesn't imply we should adopt tailwind wholesale.

I'm a little skeptical about this re-inventing tailwind from scratch setup, personally. We're getting into a weird hybrid state where some components are styled with more typical css classes and some use these composable ones, and I think it's likely to get messy and unclear which approach we should use when...

I don't think we should adopt tailwind. It has a lot of functionality I think we wouldn't want to make available to our codebase, like color palettes and media breakpoints. We already have these. I'd rather take inspiration from it where it makes sense, in limited ways.

Hmm, but even with the classes here, what's the rule of thumb for when you should make a specific css class for a component vs grouping together a bunch of these?

For example, I'm not sure why the ProjectWorkspace root would use "panel", "h-full", "w-full", "flex", "flex-col" instead of having its own class.

I actually quite like tailwind myself, so I understand the desire to have that functionality, but I'm concerned about what this in-between approach will end up looking like

I'd say rule of thumb is: don't use these classes unless it seems more natural to do so. They can be useful to inject additional css into a react-common component by className prop. I may end up not using them where I am now.

I guess I don't see what defined "where it makes sense"

where it makes sense = where functionality wouldn't conflict with existing systems. color theming and media breakpoints being two examples where conflict would occur.

For example, I'm not sure why the ProjectWorkspace root would use "panel", "h-full", "w-full", "flex", "flex-col" instead of having its own class.

I actually quite like tailwind myself, so I understand the desire to have that functionality, but I'm concerned about what this in-between approach will end up looking like

That wasn't the best use of these classes, I admit. That code evolved over time, and should have evolved once more to move flex functionality into the panel class.

If these classes are a sticking point, I can remove them. They aren't colliding with anything, but they're also just a convenience layer.

thsparks · 2024-01-31T20:14:04Z

teachertool/src/components/styling/shared.scss

+}
+
+/// Visibility
+.hidden {


Does this already exist in the react-common styles? I think it might.

Probably. I ended up not using them anyway. Removed.

thsparks

Still a little skeptical about the tailwind-like classes, but we don't need to block on it.

eanders-ms · 2024-01-31T20:58:29Z

Still a little skeptical about the tailwind-like classes, but we don't need to block on it.

I'll remove them!

srietkerk

LGTM!

eanders-ms added 2 commits January 31, 2024 07:43

add address bar

763ab95

prettier

fe19910

eanders-ms requested a review from a team January 31, 2024 15:52

eanders-ms self-assigned this Jan 31, 2024

srietkerk reviewed Jan 31, 2024

View reviewed changes

thsparks reviewed Jan 31, 2024

View reviewed changes

eanders-ms added 4 commits January 31, 2024 12:15

remove left/right pane css props

4fc0d7b

remove visible & hidden css classes

5e9bbff

rename AddressBar -> ShareLinkInput

acc6df9

remove unneeded classList

706b33f

eanders-ms requested review from srietkerk and thsparks January 31, 2024 20:31

thsparks approved these changes Jan 31, 2024

View reviewed changes

removed composable layout classes

fe42143

srietkerk approved these changes Jan 31, 2024

View reviewed changes

eanders-ms merged commit 4a2c1a1 into master Jan 31, 2024
6 checks passed

eanders-ms deleted the eanders-ms/tt-addressbar branch January 31, 2024 21:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

teacher tool: add address bar #9839

teacher tool: add address bar #9839

eanders-ms commented Jan 31, 2024 •

edited

Loading

srietkerk Jan 31, 2024

eanders-ms Jan 31, 2024

thsparks Jan 31, 2024

eanders-ms Jan 31, 2024

srietkerk Jan 31, 2024

thsparks Jan 31, 2024

eanders-ms Jan 31, 2024

srietkerk Jan 31, 2024

srietkerk Jan 31, 2024

thsparks Jan 31, 2024

srietkerk Jan 31, 2024

thsparks Jan 31, 2024

eanders-ms Jan 31, 2024

srietkerk Jan 31, 2024

eanders-ms Jan 31, 2024

eanders-ms Jan 31, 2024

srietkerk Jan 31, 2024

eanders-ms Jan 31, 2024

srietkerk Jan 31, 2024

eanders-ms Jan 31, 2024

thsparks Jan 31, 2024 •

edited

Loading

eanders-ms Jan 31, 2024

thsparks Jan 31, 2024

thsparks Jan 31, 2024

eanders-ms Jan 31, 2024

eanders-ms Jan 31, 2024

eanders-ms Jan 31, 2024

eanders-ms Jan 31, 2024

thsparks Jan 31, 2024

eanders-ms Jan 31, 2024

thsparks left a comment

eanders-ms commented Jan 31, 2024

srietkerk left a comment

teacher tool: add address bar #9839

teacher tool: add address bar #9839

Conversation

eanders-ms commented Jan 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thsparks Jan 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thsparks left a comment

Choose a reason for hiding this comment

eanders-ms commented Jan 31, 2024

srietkerk left a comment

Choose a reason for hiding this comment

eanders-ms commented Jan 31, 2024 •

edited

Loading

thsparks Jan 31, 2024 •

edited

Loading