Sure! Which one would I be contributing to?
I suspect mentioning multiple trim*
methods in the mentoring note might not have a huge amount of value. The audience is small and the mentors probably already know there are multiple trim methods. Approach docs have a much larger audience and tends to have higher value.
So there could be an approach using trim
and another using trimEnd
? If it’s just a difference of three characters, discussing it in the Dig Deeper introduction notes instead would make more sense. Maybe it could discuss possible tradeoffs (shortness vs performance)? Or maybe have both approaches & intro notes?
I would think these would be a discussion point on the same approach/dig deeper solution.
I see! I forgot that there can be extra description below the code on the approaches. That makes more sense. How would I go about adding an approach?
Here is the contributing guide for approaches. You can see the live example of Bob, and the source for that page.
Normally we’d ask people to discuss the proposed content here, but since we do not have any approaches for this exercise yet, I am cool if you create a PR and we discuss there.
I would consider:
- For getting rid of the whitespace the difference between
trim
vstrimEnd
/trimStart
vsreplace
/replaceAll
- For last character the differences between
[index]
access vsat
vscharAt
vssubString
vsslice(-1)
- To uppercase the difference between
toLocaleUpperCase
vstoUpperCase
vsString.fromCharCode(charCodeAt(0) - 32)
There are probably more approaches to be thought of, feel free to include as much or as little as you like. If you only want to tackle the trim
+ at
stuff, that’s fine. Then we’ll write the rest.
I looked through the links and I think I have some idea of how to go about creating the approach now. However, I have a question: how do you generate the unique uuid?
Thanks! I have created a draft pull request here. I have added details about all three things suggested here and added an additional method of using a loop instead of trim
/replace
for backDoorResponse
.
Right now, I’m not quite sure what to name the approach, though.
One other thing I’m not sure about is what to include in snippet.txt
.
What you can do is split the different things into different sections instead of having “first approach”. Move all content to .approaches/introduction.md
, same as javascript/exercises/practice/bob/.approaches/introduction.md at main · exercism/javascript · GitHub does.
## Different ways to implement `frontDoorPassword`
### Approach a
### Approach b
### Approach c
But a less structured approach is also fine with me:
## Different ways to implement `frontDoorPassword`
You can do A,
You can do B,
You can do C
We can try to see if the UI accepts no approach folder (and config), and merely an introduction.md. Then you also don’t need the snippet.
I did skim your PR. Good content so far!
I tried taking a fairly structured approach, and I think it turned out pretty well!
I can’t see if it accepts an introduction without approaches yet, though, as it seems the workflows need approval.
@SleeplessByte do you know how I can get the javascript / format / verify
check to pass on introduction.md
? It says “Code style issues found in the above file. Run Prettier with --write to fix.” Any help would be appreciated.
You can hand edit the file or just install Prettier locally and use that tool for format the file.
On our repo we can run an auto format. Let me do that.
Thanks! I did a “Trigger builds” commit and now the workflows are pending approval.
I’ve marked the pull request as ready for review now.
Reviewed & Approved. Few nit-picks left you can fix and then we can merge.
Thanks! I accepted most of the suggestions and took a look at the style guide. Regarding linking .at()
to MDN, I didn’t put the link there because I had it in the introduction, where it was first mentioned. Would it be better to add the link there because it’s a while after the intro or keep only one instance of the link?