jiebi/CodeConvo huggingface dataset:
Code change:
I did not see anyone raising this issue, but I don't think the background of the preview in default or night mode should be anything other than white unless the coding exercise specifically changes the background to something else. The preview should be exactly what you would see in a browser. In almost all the challenges, the background would be white. !
I share your concerns The reason we changed the color of the display is that a white display is discomforting to the eye on night mode when everything else is dark. so we injected some styles to harmonize the view in general. That convention was carried over to light mode.
It might be better to default to white in light mode, same as the editor. As for night mode, some of the css challenges might need some changes to look reasonable in both modes. For instance, in night mode, looks like this: ! If we change the seed code to it would become ! It would have to be case-by-case, though.
That is a very good point. I will defer this to
Logically, I have to agree with - displaying anything other than what the code in the editor would produce might confuse campers. But it is a little rough on the eyes to have the white background on night mode. And the current theme looks a lot better - so it's a tough call. I scrolled through a number of challenges, and there's quite a few that don't look right with the blue background. So there might be a decent amount of work to go through and fix all of them.
I really like the new theme, but a preview should be a true preview. We want to make this like the real world. Developers working in some kind of night mode on their favorite local editors, still expect to check the "real" result of the code they have written on a browser or in a preview mode in their local editors. The night mode should only apply to the editor or the non-preview part of the FCC site. Anything else is just not realistic.
The preview should be white.
I agree with everyone here on this thread. The preview should remain white. Note that soon the preview won't always be there on the right side "brightening up" the user interface and ruining people's night mode experience. Soon we will have a single column layout where you the preview only shows up when you click a button to show it, or it loads in a separate tab. - could you update the styling on this so that the preview area is unaffected by our styling?
Definitely.

Related discussion:
text: .then(checkFilesErrors) .then(files => ({ challengeType: challengeTypes.html, <del> build: concatHtml({ required: finalRequires, template, files, theme }), </del> <ins> build: concatHtml({ required: finalRequires, template, files }), </ins> sources: buildSourceMap(files), loadEnzyme }));
Code change:
<img width="616" alt="Screen Shot 2019-10-01 at 3 26 24 PM" src="https://user-"This is a picture of my own private profile locally, seems like it should say something like "You have not made your profile public" instead of "mot01 has not made their profile public" And as I'm typing this, I'm wondering if a profile should render completely if it's theirs, even if it's not public - there's no way for a user to see what their profile would look like if they don't have it public.
That does look better. The next sentence should be something like "You need to change your privacy settings in order for other people to view your profile". So, they should be able to preview their public profile, basically? Sounds good. If going that route, it would be good to emphasise (even more than currently) that their preview is not public. It wouldn't be good if people went to their preview, saw that it looked right and didn't notice that they were the only people that could see it.
Yes to this, please open a PR. It seems to have been an oversight. I think it's fair to leave the warning on their own pages while showing this page in that case, which means we may need to update the copy for them.
Can you clarify what you want here I'm not sure I understand - do we want to keep the page how it is, and just change the two sentences? Or do we want to display their private profile for them?
Yes. Sorry about being vague last time. I thought about this a little more and I think we should show the users their own profile only when they are signed in. Here is what we should achieve at the end of the day: profiles which are public are visible by default. settings button is only available if the user is on their own profile page. who are not signed in and are visiting profiles which are not public and are not their own are shown the current notice and warnings: ! who are signed in and are visiting their own private profiles are shown the same notice as the above screenshot in point 3 with the verbiage stating "You" and the settings button available. The rest of the their profile is visible as a preview.
So, there'd be a button on their private profile labelled 'Preview profile' and a label 'preview how your profile would look if you made it public'. Clicking that would take them to, say, which shows the preview (and a notice saying that it's currently private). Something like that?
Nope, we do not need a new route. Their profiles can be rendered just below the notice like so: ! Here is the copy: You have not made your profile public. You need to change your privacy setting in order for your profile to be seen by others. This is a preview of how your profile will look when made public.

Related discussion:
text: FormGroup, ControlLabel, Button, <del> Col </del> <ins> Col, Row </ins> } from '@freecodecamp/react-bootstrap'; import Helmet from 'react-helmet';
Code change:
Is there any reason not to put the real and in ? I reflexively put in a dummy key when I set this up, but now that I revisit this, that seems like a mistake.
Yes, actually it broke the .dev build unsurprisingly , I think noticed it and reported in the team chat. My bad for not catching this previously. The real fix is to ignore and move ahead when the keys are not available are default. We do this with google application credentials.
Oh, I assume it broke the build because .dev isn't using I didn't think of that... So, we should implement the fix and add the public keys to , right?
I was thinking something more along the lines of (example from api-server): I would try to avoid hundreds of contributors hitting the indexes locally. Ideally people should get their own keys. While the key and index is public, it's still not recommended to hit it?
As for the production keys, it's actually fine because the build should fail. I have since the keys in the build pipeline.
One thing: if we don't want contributors spamming search (fair enough!) I think there should be some docs that let people know what's what. Either that search isn't available in development or the steps they need to take to make it work.
I agree. We should add some docs on getting keys, or perhaps creating a test index and sharing that instead

Related discussion:
text: <del> require('dotenv').config(); </del> <ins> const env = require('../config/env'); </ins> const { createFilePath } = require('gatsby-source-filesystem');
Code change:
Is there any reason not to put the real and in ? I reflexively put in a dummy key when I set this up, but now that I revisit this, that seems like a mistake.
Yes, actually it broke the .dev build unsurprisingly , I think noticed it and reported in the team chat. My bad for not catching this previously. The real fix is to ignore and move ahead when the keys are not available are default. We do this with google application credentials.
Oh, I assume it broke the build because .dev isn't using I didn't think of that... So, we should implement the fix and add the public keys to , right?
I was thinking something more along the lines of (example from api-server): I would try to avoid hundreds of contributors hitting the indexes locally. Ideally people should get their own keys. While the key and index is public, it's still not recommended to hit it?
As for the production keys, it's actually fine because the build should fail. I have since the keys in the build pipeline.
One thing: if we don't want contributors spamming search (fair enough!) I think there should be some docs that let people know what's what. Either that search isn't available in development or the steps they need to take to make it work.
I agree. We should add some docs on getting keys, or perhaps creating a test index and sharing that instead

Related discussion:
text: } }; <del> exports.createPages = function createPages({ graphql, actions }) { </del> <ins> exports.createPages = function createPages({ graphql, actions, reporter }) { if (!env.algoliaAPIKey || !env.algoliaAppId) { if (process.env.FREECODECAMP_NODE_ENV === 'production') { throw new Error( 'Algolia App id and API key are required to start the client!' ); } else { reporter.info( 'Algolia keys missing or invalid. Required for search to yield results.' ); } } </ins> const { createPage } = actions; return new Promise((resolve, reject) => {
Code change:
Is there any reason not to put the real and in ? I reflexively put in a dummy key when I set this up, but now that I revisit this, that seems like a mistake.
Yes, actually it broke the .dev build unsurprisingly , I think noticed it and reported in the team chat. My bad for not catching this previously. The real fix is to ignore and move ahead when the keys are not available are default. We do this with google application credentials.
Oh, I assume it broke the build because .dev isn't using I didn't think of that... So, we should implement the fix and add the public keys to , right?
I was thinking something more along the lines of (example from api-server): I would try to avoid hundreds of contributors hitting the indexes locally. Ideally people should get their own keys. While the key and index is public, it's still not recommended to hit it?
As for the production keys, it's actually fine because the build should fail. I have since the keys in the build pipeline.
One thing: if we don't want contributors spamming search (fair enough!) I think there should be some docs that let people know what's what. Either that search isn't available in development or the steps they need to take to make it work.
I agree. We should add some docs on getting keys, or perhaps creating a test index and sharing that instead

Related discussion:
text: const DEBOUNCE_TIME = 100; <del> const searchClient = algoliasearch(algoliaAppId, algoliaAPIKey); </del> <ins> // If a key is missing, searches will fail, but the client will still render. const searchClient = algoliaAppId && algoliaAPIKey ? algoliasearch(algoliaAppId, algoliaAPIKey) : {}; </ins> const propTypes = { children: PropTypes.any,
Code change:
Is there any reason not to put the real and in ? I reflexively put in a dummy key when I set this up, but now that I revisit this, that seems like a mistake.
Yes, actually it broke the .dev build unsurprisingly , I think noticed it and reported in the team chat. My bad for not catching this previously. The real fix is to ignore and move ahead when the keys are not available are default. We do this with google application credentials.
Oh, I assume it broke the build because .dev isn't using I didn't think of that... So, we should implement the fix and add the public keys to , right?
I was thinking something more along the lines of (example from api-server): I would try to avoid hundreds of contributors hitting the indexes locally. Ideally people should get their own keys. While the key and index is public, it's still not recommended to hit it?
As for the production keys, it's actually fine because the build should fail. I have since the keys in the build pipeline.
One thing: if we don't want contributors spamming search (fair enough!) I think there should be some docs that let people know what's what. Either that search isn't available in development or the steps they need to take to make it work.
I agree. We should add some docs on getting keys, or perhaps creating a test index and sharing that instead

Related discussion:
text: module.exports = Object.assign(locations, { locale, stripePublicKey, <del> algoliaAppId, algoliaAPIKey </del> <ins> algoliaAppId: !algoliaAppId || algoliaAppId === 'Algolia app id from dashboard' ? null : algoliaAppId, algoliaAPIKey: !algoliaAPIKey || algoliaAPIKey === 'Algolia api key from dashboard' ? null : algoliaAPIKey </ins> });
Code change:
Is there any reason not to put the real and in ? I reflexively put in a dummy key when I set this up, but now that I revisit this, that seems like a mistake.
Yes, actually it broke the .dev build unsurprisingly , I think noticed it and reported in the team chat. My bad for not catching this previously. The real fix is to ignore and move ahead when the keys are not available are default. We do this with google application credentials.
Oh, I assume it broke the build because .dev isn't using I didn't think of that... So, we should implement the fix and add the public keys to , right?
I was thinking something more along the lines of (example from api-server): I would try to avoid hundreds of contributors hitting the indexes locally. Ideally people should get their own keys. While the key and index is public, it's still not recommended to hit it?
As for the production keys, it's actually fine because the build should fail. I have since the keys in the build pipeline.
One thing: if we don't want contributors spamming search (fair enough!) I think there should be some docs that let people know what's what. Either that search isn't available in development or the steps they need to take to make it work.
I agree. We should add some docs on getting keys, or perhaps creating a test index and sharing that instead

Related discussion:
text: ROLLBAR_CLIENT_ID='post_client_id from rollbar dashboard' ALGOLIA_ADMIN_KEY=123abc <del> ALGOLIA_APP_ID=ACDEFG ALGOLIA_API_KEY=123abc </del> <ins> ALGOLIA_APP_ID='Algolia app id from dashboard' ALGOLIA_API_KEY='Algolia api key from dashboard' </ins> AUTH0_CLIENT_ID=stuff AUTH0_CLIENT_SECRET=stuff
Code change:
The font size for the CTA could use similar breakpoints for the h1, h2. and set to 1.2 - 1.3 rem !
I'd like to work on this.
can i?
Where is this button?

Related discussion:
text: h3 { font-size: 1rem; } <ins> .btn-cta { font-size: 1.2rem; } </ins> } .text-center {
Code change:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --Describe your problem and how to reproduce it: I feel like the description for the code in the is a little confusing and can be further cliarified. For example, the description is this: "... Like strings, arrays use <dfnzero-based</dfnindexing, so the first element in an array is element <code0</code." <strongExample</strongTo be a little more clear and following the index concept, this could possibly be explained like this: "... Like strings, arrays use <dfnzero-based</dfnindexing, so the first element in an array is element at index <code0</code."

Related discussion:
text: ## Description <section id='description'> We can access the data inside arrays using <dfn>indexes</dfn>. <del> Array indexes are written in the same bracket notation that strings use, except that instead of specifying a character, they are specifying an entry in the array. Like strings, arrays use <dfn>zero-based</dfn> indexing, so the first element in an array is element <code>0</code>. </del> <ins> Array indexes are written in the same bracket notation that strings use, except that instead of specifying a character, they are specifying an entry in the array. Like strings, arrays use <dfn>zero-based</dfn> indexing, so the first element in an array has an index of <code>0</code>. </ins> <br /> <strong>Example</strong>
Code change:
Link to the challenge: Adding a global flag to the regular expression has the test fail for the first two assertions. This can be confusing considering also how the challenge is introduced, since the code snippet explaining the concept shows the global flag being used. Update the code snippet introducing the challenge: However, since the global flag should not affect the outcome of the test (to what I can ascertain), a better suggestion would be to update the test itself, to account for its presence.
Thanks for the detailed report! I think it would make sense to do both. The isn't necessary, so it should not be there and it's not wrong, so we should not reject it.
It might be better to remove the global flag from the challenge example unless we also explain how and give some info on . I think in order to really know if we should fail the test when using the global flag we would have to consider how the code is supposed to run. Are we "emulating" that each is being run in isolation or are they executed one after the other.
Agreed. This challenge focuses on teaching the user about groups - the use of over seem incidental to me, as does the presence of the flag. Also, the challenge asks you to make sure so it's only asking you to use against once.
But it is when the test is called multiple times on the same regex. Isn't this kind of the same as when users use global variables which end up causing the user's code to fail for all tests except the first because the the global variable does not get reset each time?
I'm dumb - I'd completely failed to realise it's being run twice, once in the user's code and again in the tests. You're quite right and PR fixes that.
Challenge: Fails with: Passes with:
The example/seed code moves to 14. I guess one easy option would be to change the example string to something like "Fun with regular expressions!", that should let all the tests pass and accept the global flag. The problem is if the camper uses a different string to test the regex it may fail. So we might just have to reset before running the tests.
I assumed it would be the exact same fix as what Tom did:
yep, that's what I concluded. I think we can apply Tom's fix in , rather than modifying the tests. Either works, but that should be more concise.

Related discussion:
text: ```js let testStr = "Pumpkin"; <del> let testRegex = /P(engu|umpk)in/g; </del> <ins> let testRegex = /P(engu|umpk)in/; </ins> testRegex.test(testStr); // Returns true ```
Code change:
<img width="1396" alt="Notifications_Twitter" src="https://user-"

Related discussion:
text: <Row> {!closeLabel && ( <Col sm={10} smOffset={1} xs={12}> <del> <b>Nicely done. You just completed {blockNameify(block)}.</b> </del> <ins> <b>Nicely done. You just completed {blockNameify(block)}. </b> </ins> {donationText} </Col> )}
Code change:
Describe your problem and how to reproduce it: Go to: Look for: Test outputs in the bottom-left corner Duplicated test output: Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: 79 Operating System: Mac OS 10.13.6 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
The same duplicated test output exist in the following Challenge: Go to: Look for: Test outputs in the bottom-left corner Duplicated test output: The Presentational component should render an h2, input, button, and ul elements. !
You are correct, the 2nd test should actually state: The <codePresentational</codecomponent should render to the page.
Taking this up.

Related discussion:
text: tests: - text: The <code>AppWrapper</code> should render to the page. testString: assert((function() { const mockedComponent = Enzyme.mount(React.createElement(AppWrapper)); return mockedComponent.find('AppWrapper').length === 1; })()); <del> - text: The <code>Presentational</code> component should render an <code>h2</code>, <code>input</code>, <code>button</code>, and <code>ul</code> elements. </del> <ins> - text: The <code>Presentational</code> component should render to page. </ins> testString: assert((function() { const mockedComponent = Enzyme.mount(React.createElement(AppWrapper)); return mockedComponent.find('Presentational').length === 1; })()); - text: The <code>Presentational</code> component should render an <code>h2</code>, <code>input</code>, <code>button</code>, and <code>ul</code> elements. testString: assert((function() { const mockedComponent = Enzyme.mount(React.createElement(AppWrapper)); const PresentationalComponent = mockedComponent.find('Presentational'); return ( PresentationalComponent.find('div').length === 1 && PresentationalComponent.find('h2').length === 1 && PresentationalComponent.find('button').length === 1 && PresentationalComponent.find('ul').length === 1 ); })());
Code change:
Describe your problem and how to reproduce it: As discussed at exhaustive length , the username requirements don't technically preclude the username "007". The requirement "Usernames should begin with a letter" should be . Add a Link to the page with the problem: Low-hanging fruit for a new contributor.

Related discussion:
text: Usernames are used everywhere on the internet. They are what give users a unique identity on their favorite sites. You need to check all the usernames in a database. Here are some simple rules that users have to follow when creating their username. 1) Usernames can only use alpha-numeric characters. <del> 2) The only numbers in the username have to be at the end. There can be zero or more of them at the end. </del> <ins> 2) The only numbers in the username have to be at the end. There can be zero or more of them at the end. Username cannot start with the number. </ins> 3) Username letters can be lowercase and uppercase. 4) Usernames have to be at least two characters long. A two-character username can only use alphabet letters as characters. </section>
Code change:
When navigating to and selecting a monthly donation, the text below says "Confirm your donation of X / month with PayPal" This text is coming from: There is logic elsewhere in this file that handles the different frequencies, it seems like this logic is needed here as well.
Can I try this?

Related discussion:
text: {subscriptionPayment ? ( <Fragment> <b> <del> Confirm your donation of ${donationAmount / 100} / year with PayPal: </del> <ins> Confirm your donation of ${donationAmount / 100} /{' '} {donationDuration} with PayPal: </ins> </b> <Spacer /> </Fragment>
Code change:
Describe your problem and how to reproduce it: Declaring a loop using as the declaration to solve the challenge does not pass one test. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: 80 Operating System: Windows 10 Pointed out in this forum topic:

Related discussion:
text: ```yml tests: - text: The function <code>countOnline</code> should use a `for in` statement to iterate through the object keys of the object passed to it. <del> testString: assert(code.match(/fors*(s*(var|let)s+[a-zA-Z_$]w*s+ins+[a-zA-Z_$]w*s*)s*{/)); </del> <ins> testString: assert(code.match(/fors*(s*(var|let|const)s+[a-zA-Z_$]w*s+ins+[a-zA-Z_$]w*s*)s*{/)); </ins> - text: 'The function <code>countOnline</code> should return <code>1</code> when the object <code>{ Alan: { online: false }, Jeff: { online: true }, Sarah: { online: false } }</code> is passed to it' testString: assert(countOnline(usersObj1) === 1); - text: 'The function <code>countOnline</code> should return <code>2</code> when the object <code>{ Alan: { online: true }, Jeff: { online: false }, Sarah: { online: true } }</code> is passed to it'