Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

challenge number in the app project name #884

Closed
tomalaforge opened this issue May 10, 2024 · 8 comments
Closed

challenge number in the app project name #884

tomalaforge opened this issue May 10, 2024 · 8 comments

Comments

@tomalaforge
Copy link
Owner

Should I add the number of the challenge in the app project name ?

image

If you look at the folder, should it be:

  • angular
  • 21-anchor-scrolling
  • xx-bug-cd
  • xx-bug-effect-signal

and so one.

I don't know how hard is it to find the right challenge ?

Or maybe it is correct the way it is now

What do you think ?

@tomalaforge
Copy link
Owner Author

@jdegand @svenson95 @LMFinney

@LMFinney
Copy link
Sponsor Contributor

I think 21-anchor-scrolling would work. That's what we did at https://github.com/angularbootcamp/abc, when I worked on that.

@jdegand
Copy link
Contributor

jdegand commented May 10, 2024

The eslint forbidden enum # 27 challenge is hard to find. Probably need to update the readme for that challenge to tell challengers to look under tools. No one has completed the challenge. (Updated: Check #886 for my rework).

That challenge is one where the name of challenge doesn't match the filename as well (Custom Eslint Rule vs Forbidden Enum). There are multiple challenges where this is the case.

If you add the numbers, the title and filenames don't have to match and you don't have to correct every mismatch.

It would be nice to add the numbers to the lib folders as well. But this could present a problem since I believe some lib folders having overlapping challenges.

Another thing to note -> If you change the file names to have numbers, do you have to update the generator as well?

If you plan on doing a rework, I'd also think about re-categorizing some challenges. Move interop to RxJS category. Typed ContextOutlet (and possibly Utility Wrapper Pipe) to TypeScript. But then you'd have a lot of work in changing all translation folders as well.

@LMFinney
Copy link
Sponsor Contributor

In addition to re-categorizing, I think some of the difficulty levels could be tweaked. For example, crud application wasn't hard for me, but there's a lot more code involved than in the other "easy" ones.

But to @jdegand's point, the difference between "Pure Pipe" and "pipe-easy" is a bit confusing.

@jdegand
Copy link
Contributor

jdegand commented May 11, 2024

It is worse than I thought. There's at least 15 mismatched challenges. However, the command in the readme should clue challengers to the filename of the challenge.

I think it will be signficantly easier to just change the title of the readme to match the existing filename.

This might lead to some ugly titles, but it is a quick fix and it will be less error prone. You still will have to update all translation checklists in the other issues. This could also be a stop-gap measure if you want to do a significant rework.

@svenson95
Copy link
Contributor

The challenge number would really help to navigate through the challenges. That's a good idea.

Imo it would be great if we could use matching challenge titles & filenames. As @LMFinney already mentioned, the pipe challenge titles and filenames are a bit confusing.

Re-categorizing is a good point as well. The new signal challenges should have a own signal category.

@tomalaforge
Copy link
Owner Author

tomalaforge commented May 11, 2024

thanks a lot for your feedback
I agree with the name should match the title. Very hard to find the right challenge.
And by adding the number, it will be easier as well.

I can indeed re-categorize some challenges.

@tomalaforge
Copy link
Owner Author

Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants