Question:
Expected behavior Please see attached screenshot for more details. Basically: [x] "Contact email" should be "Email Us" [x] We should get rid of the outbound link icons [ ] The footer should always go below the tallest element. Currently on the Guide, it seems to go under the least tall element. Screenshots <img width="1246" alt="echoandprint_freecodecamp_guide" src="https://user-"
Side note (perhaps a separate issue): the footer on the page is difficult to get to due to the loading of content on a scroll down. So you have to keep scrolling and keep loading content until there's no more to load to reach the footer. I suppose there would be a similar issue on the forum or anywhere else that uses the loading on a scroll.
I'll give it a try.
I have fixed the first two issues but couldn't quite reproduce the third one either in Chrome or Firefox(In Windows 10). cc - !
There is a UX trade off for doing that for implementing the third one. In order for the footer to go under the tallest element, both elements should have the height of 100% (no-scroll). In that case, when user clicks on a side nav that is taller than the content, the page should either go to the top to show the top of the content (loses the location of the scroll), or keep its scroll which means the user will scroll up and down just to change the tabs. here is a demo: ! with no footer, our layout would have behaved similar to the default Gatsby sidebar example. With the footer, the optimal solution would be to add some javascript and have a floating sidebar that stops at the footer. We could also have a fixed sidebar that the footer would overlap at the end of the page. imho, the current setup does the job, but please let me know which solution you would like me to explore.
Hi I agree with I think the key here is to use the site as an end user, and then decide on the tradeoff. I agree that the current sidebar is far better UX for the user, who are more likely browsing through an article and have it in view rather than have them scroll a long way to switch to the next topic of their interest. That will definitely increase a session time and reduce bounce rate.
That is fine. People will scroll. I think you all are dramatically overestimating the inconvenience of scrolling. On mobile, this will all be a single column layout anyway. This is what people thought was the optimal solution back in the 1990s. In practice, it's confusing to users. Users would much rather scroll up and down a page then have to move their mouse around to different "frames" and scroll up and down within those in a more confined space. Just look at this page here on GitHub. The footer is always at the bottom of the tallest column, which in this case is the middle one. If I want to see who this issue is assigned to, yes - I have to scroll back up to the top of the page. That's no big deal - it takes less than a second. We should use a similar approach with footers everywhere on freeCodeCamp. Separate horizontal scrolling portions are bad enough, and I'd like to move away from them - let alone separate vertical portions. Here's an example of how having separate scrolling areas is hurting usability on learn: <img width="1415" alt="learnbasichtmlandhtml5fillintheblankwithplaceholdertextfreecodecamporg" src="https://user-"A new user might not even realize that there are buttons and tests underneath the "run test" button. The footer should always be at the bottom of whichever column is tallest, and we should not have independently scrolling columns. At some point in the past year or two, the independently scrolling columns were introduced. could you start working on a version that puts the footer at the bottom of the tallest column?
I strongly recommend testing the app as user would to derive the best UX for our app's use case. For the Guide, I think the tallest element principle does not work in practice, you can test that locally yourself, it's just weird to scroll through whitespace vs content. People will scroll through content, not whitespace? For Learn I had given my feedback in a comment here: But, we quickly realized that the tallest element won't work either. Here is what we should do though is to use the buttons as a fixed component on learn. This gives us the ability to scroll the "content" as much as we want, while keeping the most used component buttons in our case in view. ! Also, I would like to bring light to the fact that several feedback (fairly frustrated) threads that we have had here on GitHub and forum is the ability to use the challenge map about scrolling. It works when you are casually browsing, not when you are looking for something specific. But that's a different problem unrelated to this thread. Anyways, let's start working on a version that does put the footer at the bottom of the tallest element and do a A/B test.
I will make a MVP and have you test it ASAP. Here is how Khan academy does it when the scroll meets the footer. Notice the shadow indicating that side nav is continuing and scrollable <img width="504" alt="screen shot 2019-02-12 at 9 29 49 pm" src="https://user-".
Please let me know if you wanna move forward with this design, and if you want the user to go to the top of the page after clicking the side nav or not so I could adjust it accordingly.
Please take a look at this document: Also consider this: very few people are actively looking for the footer. And if they are, they're just going to swipe down really fast and get there immediately, regardless of how tall the page is. The main purpose of the footer is SEO and for the 0.001% of people who are actively looking for it. (how many times a day do you find yourself trying to scroll down to content in a footer?) The Guide's sidebar is only 109 entries tall. It's not going to be that much space. If they have one of the bigger categories expanded, yes, it could be more. But I don't think the footer is important enough to warp the experience of the guide.
A good example of how to handle a documentation page with expandable side menu items, and a footer, without extra scrolling is the MDN: When you expand the menu items on the left, the footer just gets pushed further down the page.
with these changes, this issue will back Or am I missing something?
so I think wants the page scroll to go to zero only when a node with no children is clicked on the side nav. I cannot think of a way that I could implemented it without recording and resetting the scroll with JS, so if anything comes to your mind, let me know.
Nodes with children also have articles.
very good point, so we would be reverting to the bug, then. if the height of both elements are set to 100% our footer would be pushed down when an element is expanded; however, in the mozilla doc, Nodes with children do not have articles. So users can click on an end node on the side nav and then it page goes to the top. in our case, if a user wants to visit for example . She would be scrolling the whole side nav 3 times. If we really need to go in that direction, the other option would be not take the users to the top of the page regardless of where they click on the nav. but when they reach their destination in the sidenav tree, they will have to scroll up to see the article's beginning.
Hi IMHO, and all honesty I really do not care about the footer. Meaning we are on the same page about its priority. The idea is the best usability of the site itself. I am not advocating that we should not make it so that people do not have to scroll. All I am interested in is making the UX intuitive and not painful from a user's viewpoint. I completely agree on your well researched thoughts about scrolling. But I keep re-iterating to test the site ourselves in A/B strategy and see what works best for us. In my tests, I found it weird and awkward to scroll when I am working through challenges, or looking through guide articles (not casually browsing like on a news site). So, from my tests: On the guide, the footer should be below the content element (the right guide article itself). The content element will expand in height depending on its content. This will keep the footer out of the view at all times. That is The footer can be hidden out of view under the viewport. Your MDN example, does something same. At all times, the content block is on the top of the footer. On the learn, I think we should get rid of the internal scrolls. But this also means, we should keep three things always in view: editor (labeled 2 on my screenshot) buttons preview panel (labeled 4 on my screenshot) These are the most interacted elements on the learn app. Only the instructions (without the buttons, will scroll) The footer can be hidden out of view under the viewport.
Maybe for the challenges and guide page we could make a smaller footer similar to the one github uses.
!
Re-opening. GitHub closed it automatically. This issue will be taken care of in repeated iterations.
I believe the decision is to make the sidebar more concise so there would not be a need to scroll. Although displaying the sibling nav items were discussed, I think it would be best to move forward with something similar to the following convention where only children and parent nodes are in the sidebar. !
Yes, let's get a variation that you propose in, and test it out.
I have a couple of suggestions on the footer: I feel the links are too cramped and need a little more padding between them Headings can be simplified There should be substantial space between the block of text on the left and the links At the end, it could look somewhat like this: !
I really like your design, it definitely looks better than the current one. Here are a couple of considerations. The logo looks great, but it makes the footer area taller. As a general rule we would like to save as much screen real state as possible. To be accessible we need a way other than color to establish visual hierarchy between headings and footer items. I encourage you to take screenshot of both the current version and your design so we could compare their sizes and their white space allocation better. After that let's have a pr and merge the changes.
Also I don't think you're allowed to change the colour of logo according to https://design-style-
let us address side-nav related suggestions and improvement in the above-referenced issue so it does not get confused with the footer.
Here are the screenshots for screenshots for comparison. ! ! !
would you be interested in making the footer titles more concise as suggested?
I always have this message always poping up when i run my code "Your Footer do not all have a white color" i have done all i could but cannot detect any fault in my code. this stopped my html from running further. I gave an inline style with white as color yet the problem continued. I just don't know what to do again

return ( <a href={to} {...other} rel='noopener noreferrer' target='_blank'> {children} <del> <FontAwesomeIcon className='external-link-icon' icon={faExternalLinkAlt} size='xs' /> </del> </a> ); };


Question:
Donate modal is rendered/animated twice when invoked
Steps to reproduce. Complete at least 9 challenges. See modal once per session.
alternatively, change this line to true and get the modal after completion of each challenge.
Just in case someone tackle this before I get back to it. it seems like the app gets updated after the donate modal is up. so that might be causing the flashing. redux devtools actions order: <img width="338" alt="screen shot 2019-02-22 at 6 46 38 pm" src="https://user-"devtoolds error: <img width="642" alt="screen shot 2019-02-23 at 12 19 40 pm" src="https://user-"and here is where the modal is being called:

import { userSelector, isSignedInSelector, <del> openDonationModal, showDonationSelector, </del> submitComplete, updateComplete, updateFailed


Question:
Donate modal is rendered/animated twice when invoked
Steps to reproduce. Complete at least 9 challenges. See modal once per session.
alternatively, change this line to true and get the modal after completion of each challenge.
Just in case someone tackle this before I get back to it. it seems like the app gets updated after the donate modal is up. so that might be causing the flashing. redux devtools actions order: <img width="338" alt="screen shot 2019-02-22 at 6 46 38 pm" src="https://user-"devtoolds error: <img width="642" alt="screen shot 2019-02-23 at 12 19 40 pm" src="https://user-"and here is where the modal is being called:

'project.backEnd': submitProject }; <del> function shouldShowDonate(state) { return showDonationSelector(state) ? of(openDonationModal()) : empty(); } </del> export default function completionEpic(action$, state$) { return action$.pipe( ofType(types.submitChallenge), switchMap(({ type }) => { const state = state$.value; const meta = challengeMetaSelector(state); <del> const { isDonating } = userSelector(state); </del> const { nextChallengePath, introPath, challengeType } = meta; <del> const showDonate = isDonating ? empty() : shouldShowDonate(state); </del> const closeChallengeModal = of(closeModal('completion')); let submitter = () => of({ type: 'no-user-signed-in' }); if (


Question:
Donate modal is rendered/animated twice when invoked
Steps to reproduce. Complete at least 9 challenges. See modal once per session.
alternatively, change this line to true and get the modal after completion of each challenge.
Just in case someone tackle this before I get back to it. it seems like the app gets updated after the donate modal is up. so that might be causing the flashing. redux devtools actions order: <img width="338" alt="screen shot 2019-02-22 at 6 46 38 pm" src="https://user-"devtoolds error: <img width="642" alt="screen shot 2019-02-23 at 12 19 40 pm" src="https://user-"and here is where the modal is being called:

return submitter(type, state).pipe( tap(() => navigate(introPath ? introPath : nextChallengePath)), concat(closeChallengeModal), <del> concat(showDonate), </del> filter(Boolean) ); })


Question:
Donate modal is rendered/animated twice when invoked
Steps to reproduce. Complete at least 9 challenges. See modal once per session.
alternatively, change this line to true and get the modal after completion of each challenge.
Just in case someone tackle this before I get back to it. it seems like the app gets updated after the donate modal is up. so that might be causing the flashing. redux devtools actions order: <img width="338" alt="screen shot 2019-02-22 at 6 46 38 pm" src="https://user-"devtoolds error: <img width="642" alt="screen shot 2019-02-23 at 12 19 40 pm" src="https://user-"and here is where the modal is being called:

import { isSignedInSelector, currentChallengeIdSelector, <ins> openDonationModal, showDonationSelector, </ins> updateComplete, <del> updateFailed </del> <ins> updateFailed, userSelector </ins> } from '../../../redux'; import { post } from '../../../utils/ajax';


Question:
Donate modal is rendered/animated twice when invoked
Steps to reproduce. Complete at least 9 challenges. See modal once per session.
alternatively, change this line to true and get the modal after completion of each challenge.
Just in case someone tackle this before I get back to it. it seems like the app gets updated after the donate modal is up. so that might be causing the flashing. redux devtools actions order: <img width="338" alt="screen shot 2019-02-22 at 6 46 38 pm" src="https://user-"devtoolds error: <img width="642" alt="screen shot 2019-02-23 at 12 19 40 pm" src="https://user-"and here is where the modal is being called:

yield put(updateSuccessMessage(randomCompliment())); } <ins> function* showDonateModalSaga() { let { isDonating } = yield select(userSelector); let shouldShowDonate = yield select(showDonationSelector); if (!isDonating && shouldShowDonate) { yield put(openDonationModal()); } } </ins> export function createCurrentChallengeSaga(types) { return [ takeEvery(types.challengeMounted, currentChallengeSaga), <del> takeEvery(types.challengeMounted, updateSuccessMessageSaga) </del> <ins> takeEvery(types.challengeMounted, updateSuccessMessageSaga), takeEvery(types.challengeMounted, showDonateModalSaga) </ins> ]; }


Question:
Describe your problem and how to reproduce it: Anchor links such is not working properly in several languages. For sure is not working in: Russian, Spanish, Chinese languages. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 74.0.3729.169 (Official Build) (64-bit) Operating System: Windows 10 Pro 1809 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
These 3/4 PRs (exlude one - which I PR'd to my own forked-repo) may close this issue. Please review them.

Вы можете внести свой вклад в интересующую вас область: <del> 1. [Внести вклад в этот открытый репозиторий.](#contribute-to-this-open-source-codebase) </del> <ins> 1. [Внести вклад в этот открытый репозиторий.](#внести-свой-вклад-в-этот-open-source-проект) </ins> Помогите нам в создании или редактировании [обучающих статей](https://www.freecodecamp.org/guide), [задач по программированию](https://www.freecodecamp.org/learn) или исправлении ошибок на нашей обучающей платформе.


Question:
Describe your problem and how to reproduce it: Anchor links such is not working properly in several languages. For sure is not working in: Russian, Spanish, Chinese languages. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 74.0.3729.169 (Official Build) (64-bit) Operating System: Windows 10 Pro 1809 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
These 3/4 PRs (exlude one - which I PR'd to my own forked-repo) may close this issue. Please review them.

Вы можете помочь нам: <del> - [📝 В исследовании, написании и обновлении статей нашего руководства.](#research-write-and-update-our-guide-articles) </del> <ins> - [📝 В исследовании, написании и обновлении статей нашего руководства.](#изучение-написание-и-обновление-статей-нашего-руководства) </ins> <del> - [💻 В создании, обновлении и исправлении ошибок в наших задачах по программированию.](#create-update-and-fix-bugs-in-our-curriculum-challenges) </del> <ins> - [💻 В создании, обновлении и исправлении ошибок в наших задачах по программированию.](#создание-обновление-и-исправление-ошибок-в-наших-задачах-на-кодирование) </ins> <del> - [🌐 В переводе обучающих статей и задач по программированию.](#translate-guide-articles-and-curriculum-challenges) </del> <ins> - [🌐 В переводе обучающих статей и задач по программированию.](#перевод-статей-руководства-и-задач-на-кодирование) </ins> <del> - [🛠 В исправлении ошибок на обучающей платформе freeCodeCamp.org](#help-us-fix-bugs-in-freecodecamporgs-learning-platform) </del> <ins> - [🛠 В исправлении ошибок на обучающей платформе freeCodeCamp.org](#помогите-нам-исправить-ошибки-в-обучающей-платформе-freecodecamporg) </ins> ### Изучение, написание и обновление статей нашего руководства


Question:
Describe your problem and how to reproduce it: Anchor links such is not working properly in several languages. For sure is not working in: Russian, Spanish, Chinese languages. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 74.0.3729.169 (Official Build) (64-bit) Operating System: Windows 10 Pro 1809 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
These 3/4 PRs (exlude one - which I PR'd to my own forked-repo) may close this issue. Please review them.

Puedes optar por contribuir a cualquier área de tu interés: <del> 1. [Contribuir a esta base de código fuente abierto.](#contribute-to-this-open-source-codebase) </del> <ins> 1. [Contribuir a esta base de código fuente abierto.](#contribuye-a-esta-base-de-código-abierto) </ins> Ayúdanos a crear o editar [artículos de guía](https://www.freecodecamp.org/guide), [desafíos de codificación](https://www.freecodecamp.org/learn) o a corregir errores en la plataforma de aprendizaje.


Question:
Describe your problem and how to reproduce it: Anchor links such is not working properly in several languages. For sure is not working in: Russian, Spanish, Chinese languages. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 74.0.3729.169 (Official Build) (64-bit) Operating System: Windows 10 Pro 1809 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
These 3/4 PRs (exlude one - which I PR'd to my own forked-repo) may close this issue. Please review them.

Puedes ayudarnos a: <del> - [📝 Investigar, escribir y actualizar nuestras guías.](#investiga-escribe-y-actualiza-nuestros-artículos-de-guía) </del> <ins> - [📝 Investigar, escribir y actualizar nuestras guías.](#investiga-escribe-y-actualiza-nuestras-guías) </ins> - [💻 Crear, actualizar y corregir errores en nuestros desafíos de código.](#crear-actualizar-y-corregir-errores-en-nuestros-desafíos-de-codificación) - [🌐 Traducir artículos de guía y desafíos de código.](#traducir-artículos-de-guía-y-desafíos-de-codificación) <del> - [🛠 Corregir errores en la plataforma de aprendizaje de freeCodeCamp.org.](#ayúdenos-a-corregir-errores-en-la-plataforma-de-aprendizaje-de-freeCodeCamp.org) </del> <ins> - [🛠 Corregir errores en la plataforma de aprendizaje de freeCodeCamp.org.](#investiga-escribe-y-actualiza-nuestras-guías) </ins> ### Investiga, escribe y actualiza nuestras guías


Question:
Describe your problem and how to reproduce it: Anchor links such is not working properly in several languages. For sure is not working in: Russian, Spanish, Chinese languages. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 74.0.3729.169 (Official Build) (64-bit) Operating System: Windows 10 Pro 1809 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
These 3/4 PRs (exlude one - which I PR'd to my own forked-repo) may close this issue. Please review them.

3. 帮助我们为[YouTube频道视频](https://www.youtube.com/channel/UC8butISFwT-Wl7EV0hUK0BQ/videos)添加字幕。 <del> ##贡献予开源代码库 </del> <ins> ## 贡献予开源代码库 </ins> 我们有数以千计的[编码挑战](https://learn.freecodecamp.org)和[指南文章](https://guide.freecodecamp.org)集中在这个庞大的开源代码库中。


Question:
Describe your problem and how to reproduce it: Anchor links such is not working properly in several languages. For sure is not working in: Russian, Spanish, Chinese languages. Add a Link to the page with the problem: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: Version 74.0.3729.169 (Official Build) (64-bit) Operating System: Windows 10 Pro 1809 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): !
These 3/4 PRs (exlude one - which I PR'd to my own forked-repo) may close this issue. Please review them.

- [📝 研究，编写和更新我们的指南文章](#研究编写和更新我们的指南文章) <del> - [💻 创建，更新编码挑战和修复其中的错误](创建更新编码挑战和修复其中的错误) </del> <ins> - [💻 创建，更新编码挑战和修复其中的错误](#创建更新编码挑战和修复其中的错误) </ins> - [🌐 翻译指南文章和编码挑战](#翻译指南文章和编码挑战) <del> - [🛠 帮助我们修复freeCodeCamp.org学习平台中的错误](#帮助我们修复freeCodeCamp.org学习平台中的错误) </del> <ins> - [🛠 帮助我们修复freeCodeCamp.org学习平台中的错误](#帮助我们修复freecodecamporg学习平台中的错误) </ins> ### 研究，编写和更新我们的指南文章


Question: Describe your problem and how to reproduce it: Link to "Guide website" is different from English version. Portuguese version is redirecting to "". English version is redirecting to "". Add a Link to the page with the problem: English version Portuguese version Tell us about your browser and operating system: Browser Name: FireFox Browser Version: 68.0 Operating System: Windows 10 Professional

1. [Contribua para essa base de códigos abertos.](#contribua-para-essa-base-de-códigos-abertos) <del> Nos ajude criando e editando [Artigos de guias](https://www.freecodecamp.org/guide), [desafios de código](https://www.freecodecamp.org/learn) e corrigindo bugs na plataforma de aprendizado. </del> <ins> Nos ajude criando e editando [Artigos de guias](https://guide.freecodecamp.org), [desafios de código](https://www.freecodecamp.org/learn) e corrigindo bugs na plataforma de aprendizado. </ins> 2. Ajude campistas em nosso [fórum público](https://www.freecodecamp.org/forum/).


Question:
Challenge: Video: The code is supposed to create a two-column layout but there is a typo. Video has: Should be: It would be nice to have the video fixed if possible.
I would like to help but I need some more information like the download link for the video to edit it and overwrite columns on colums.
Is it possible to get this video updated?
this still needs to be fixed, if possible.

id: 5a94fe8569fb03452672e464 title: Create Grids within Grids challengeType: 0 <del> videoUrl: 'https://scrimba.com/p/pByETK/c6N78Ap' </del> forumTopicId: 301128 ---


Question:
Front end project pages have no margin and hug the window: <img width="370" alt="Screen Shot 2019-08-20 at 9 12 57 AM" src="https://user-"All other pages have a margin I believe: <img width="373" alt="Screen Shot 2019-08-20 at 9 12 48 AM" src="https://user-"I can fix this one
from the screenshots. does adding a padding that way causes a horizontal scroll?
No, I'm pretty sure that's just my firefox being goofy again - that screenshot is from .dev and it shows this at the bottom on my firefox... <img width="319" alt="Screen Shot 2019-08-23 at 7 40 55 AM" src="https://user-"causing the horizontal scroll bar to appear, but it's fine on chrome.
That should get fixed by , unless there's some other stuff overflowing. It just needs
Thinking about it: do you want to make that change in your PR as well, That way you can see if there are any other problems.
Looks like it might not be my firefox - I found that when signed in, it displays the button in the picture above - but when not signed in, the button says "I've completed this challenge" So it's not the margin causing the scrollbar.
looks like that property does fix the scrollbar issue - <img width="292" alt="Screen Shot 2019-08-23 at 8 23 25 AM" src="https://user-"but it's strange that the button displays different text based on authentication

align-items: center; max-width: 960px; margin: 0 auto; <ins> padding: 0 15px; </ins> }


Question:
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.

padding: 0; margin: 0; border: none; <ins> background-color: white; </ins> } .enable-iframe {


Question:
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.

} from 'lodash'; import { compileHeadTail, setExt, transformContents } from '../utils/polyvinyl'; <del> import { nightThemeStyle } from './displayStyle.js'; </del> const htmlCatch = 'n<!--fcc-->n'; const jsCatch = 'n;/*fcc*/n';


Question:
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.

[stubTrue, identity] ]); <del> export function concatHtml({ required = [], template, files = [], theme = 'night' } = {}) { theme = theme === '' ? 'night' : theme; </del> <ins> export function concatHtml({ required = [], template, files = [] } = {}) { </ins> const createBody = template ? _template(template) : defaultTemplate; <del> const displayTheme = theme === 'night' ? nightThemeStyle : ` `; </del> const head = required .map(({ link, src }) => { if (link && src) {


Question:
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.

} return ''; }) <del> .reduce((head, element) => head.concat(element), displayTheme); </del> <ins> .reduce((head, element) => head.concat(element)); </ins> const source = files.reduce( (source, file) => source.concat(file.contents, htmlCatch),


Question:
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.

<del> export const nightThemeStyle = ` <style> html{ color: white; } a { color: #99c9ff; } </style> `; </del>


Question:
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.

import { createExecuteChallengeSaga } from './execute-challenge-saga'; import { createCurrentChallengeSaga } from './current-challenge-saga'; import { challengeTypes } from '../../../../utils/challengeTypes'; <del> import { userSelector } from '../../../redux'; </del> export const ns = 'challenge'; export const backendNS = 'backendChallenge';


Question:
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.

state[ns].projectFormValues || {}; export const challengeDataSelector = state => { <del> const { theme } = userSelector(state); </del> const { challengeType } = challengeMetaSelector(state); let challengeData = { challengeType }; if (


Question:
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.

template }; } <del> challengeData.theme = theme; </del> return challengeData; };


Question:
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.

runTestInTestFrame(document, testString, testTimeout); } <del> export function buildDOMChallenge({ files, required = [], template = '', theme = `` }) { </del> <ins> export function buildDOMChallenge({ files, required = [], template = '' }) { </ins> const finalRequires = [...globalRequires, ...required, ...frameRunner]; const loadEnzyme = Object.keys(files).some(key => files[key].ext === 'jsx'); const toHtml = [jsToHtml, cssToHtml];


Question:
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.

.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 }));


Question: Is there a reason the certifications have an apparent margin above them? ! It's bigger with a taller viewport. Seems like there should be no margin there.

} .certification-namespace.certificate-wrapper { <del> top: calc(100vh / 20); position: relative; </del> font-family: 'Sax Mono', monospace; }


Question:
<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.

FormGroup, ControlLabel, Button, <del> Col </del> <ins> Col, Row </ins> } from '@freecodecamp/react-bootstrap'; import Helmet from 'react-helmet';


Question:
<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.

} const { textarea } = this.state;  const placeholderText = `Please provide as much detail as possible about the account or behavior you are reporting.`;  return ( <Fragment> <Helmet> <title>Report a users profile | freeCodeCamp.org</title> </Helmet>  <FullWidthRow> <Spacer size={2} /> <Col md={8} mdOffset={2}>   <Spacer size={2} /> <Row className='text-center'> <Col sm={8} smOffset={2} xs={12}>
 Do you want to report {username} 's profile for abuse?
  </Col> </Row> <Row> <Col sm={6} smOffset={3} xs={12}>
 We will notify the community moderators' team, and a send copy of  this report to your email:{' '} {email}.   this report to your email: {email}

We may get back to you for more information, if required.
 <form onSubmit={this.handleSubmit}> <FormGroup controlId='report-user-textarea'>  <ControlLabel>Additional Information</ControlLabel>   <ControlLabel>What would you like to report?</ControlLabel>  <FormControl componentClass='textarea' onChange={this.handleChange}  placeholder=''   placeholder={placeholderText}  value={textarea} /> </FormGroup> <Button block={true} bsStyle='primary' type='submit'> Submit the report </Button>  <Spacer />  </form> </Col>  </FullWidthRow>   </Row>  </Fragment> ); }


Question:
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

<del> require('dotenv').config(); </del> <ins> const env = require('../config/env'); </ins> const { createFilePath } = require('gatsby-source-filesystem');


Question:
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

} }; <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) => {


Question:
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

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,


Question:
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

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> });


Question:
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

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


Question:
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?

h3 { font-size: 1rem; } <ins> .btn-cta { font-size: 1.2rem; } </ins> } .text-center {


Question: <!-- 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."

## Description
 We can access the data inside arrays using <dfn>indexes</dfn>.  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 0.   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 0.
 Example


Question:
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.

```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 ```


Question:
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.

```yml tests: - text: Your regex myRegex should return true for the string Franklin D. Roosevelt  testString: assert(myRegex.test('Franklin D. Roosevelt'));   testString: myRegex.lastIndex = 0; assert(myRegex.test('Franklin D. Roosevelt'));  - text: Your regex myRegex should return true for the string Eleanor Roosevelt  testString: assert(myRegex.test('Eleanor Roosevelt'));   testString: myRegex.lastIndex = 0; assert(myRegex.test('Eleanor Roosevelt'));  - text: Your regex myRegex should return false for the string Franklin Rosevelt  testString: assert(!myRegex.test('Franklin Rosevelt'));   testString: myRegex.lastIndex = 0; assert(!myRegex.test('Franklin Rosevelt'));  - text: You should use .test() to test the regex. testString: assert(code.match(/myRegex.test(s*myStrings*)/)); - text: Your result should return true.


Question: <img width="1396" alt="Notifications_Twitter" src="https://user-"

<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> )}


Question:
<img width="682" alt="Screen Shot 2020-02-03 at 7 30 48 PM" src="https://user-"For some reason, the font changes halfway down this introduction. . I don't see the problem at first glance. Probably just a spacing issue or something.
Hi . It looks like the problem caused by HTML tags in the text. I removed them and it looks better. Please check PR.

--- ## Introduction to the Managing Packages with npm Challenges  The Node Package Manager (npm) is a command-line tool used by developers to share and control modules (or packages) of JavaScript code written for use with Node.js.

When starting a new project, npm generates a package.json file. This file lists the package dependencies for your project. Since npm packages are regularly updated, the package.json file allows you to set specific version numbers for each dependency. This ensures that updates to a package don't break your project.

npm saves packages in a folder named node_modules. These packages can be installed in two ways:

globally in a root node_modules folder, accessible by all projects.

locally within a project's own node_modules folder, accessible only to that project.

Most developers prefer to install packages local to each project to create a separation between the dependencies of different projects. Working on these challenges will involve you writing your code on Glitch on our starter project. After completing each challenge you can copy your public Glitch url (to the homepage of your app) into the challenge screen to test it! Optionally you may choose to write your project on another platform but it must be publicly visible for our testing.
Start this project on Glitch using this link or clone this repository on GitHub! If you use Glitch, remember to save the link to your project somewhere safe!   The Node Package Manager (npm) is a command-line tool used by developers to share and control modules (or packages) of JavaScript code written for use with Node.js.

When starting a new project, npm generates a package.json file. This file lists the package dependencies for your project. Since npm packages are regularly updated, the package.json file allows you to set specific version numbers for each dependency. This ensures that updates to a package don't break your project. npm saves packages in a folder named node_modules. These packages can be installed in two ways: 1. globally in a root node_modules folder, accessible by all projects. 2. locally within a project's own node_modules folder, accessible only to that project. Most developers prefer to install packages local to each project to create a separation between the dependencies of different projects. Working on these challenges will involve you writing your code on Glitch on our starter project. After completing each challenge you can copy your public Glitch url (to the homepage of your app) into the challenge screen to test it! Optionally you may choose to write your project on another platform but it must be publicly visible for our testing. Start this project on Glitch using this link or clone this repository on GitHub! If you use Glitch, remember to save the link to your project somewhere safe!


Question:
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.

tests: - text: The AppWrapper should render to the page. testString: assert((function() { const mockedComponent = Enzyme.mount(React.createElement(AppWrapper)); return mockedComponent.find('AppWrapper').length === 1; })());  - text: The Presentational component should render an h2, input, button, and ul elements.   - text: The Presentational component should render to page.  testString: assert((function() { const mockedComponent = Enzyme.mount(React.createElement(AppWrapper)); return mockedComponent.find('Presentational').length === 1; })()); - text: The Presentational component should render an h2, input, button, and ul 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 ); })());


Question: 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.

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>


Question: The logs for are quite verbose for some reason, making checking CI failures etc very difficult. Currently is logging all the solution, code etc for challenges? We need to avoid this.

script.innerHTML = tryTransform(babelTransformCode(babelOptionsJS))( script.innerHTML ); <del> console.log('transformed:', script.innerHTML); </del> }); }


Question:
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?

{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>


Question: 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:

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


Question:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --This is a problem I found in the "Applied Visual Design: Set the font-size for Multiple Heading Elements".Even though the styling of headers in this challenge may be correct,the console gives an error stating that "h6" is not properly styled. I figured this may be due to the minimum-font-size issue of the browsers usually set to 15 or 16px(In Google Chrome and Firefox). Just wondered if we can put a note on the left pane where the question is present. Link Browser Name: Google Chrome Browser Version: 80.0.3987.116 Operating System: Linux
Yes, I believe this has come up before. I would rather see the use regex I think.
But this issue comes up every now and then in the forum. How is it possible for a beginner to use regex in this challenge ocnsidering that they may be only a few days into the course
I meant to use regex to test that users entered "14px". Not that users should use regex at all. Right now the test is checking the value of the as it is rendered by the browser. If we check the input from the user, it wouldn't matter what size the browser gave the element.
I am new to Open Source Contributions,can you guide me on fixing this issue?
I would recommend following the . After that you need to fix the file I linked above and make a pull request. You can also reach out to us in our
Hi How would you target the element inside the tag, as it's inside HTML?
I don't understand. You want to check the CSS of the . Right?
The first part, , isolates the styles for the class. Then you can more easily find if the correct styles are in there.
Thanks It was the variable that I was missing

- text: Your code should set the font-size property for the h5 tag to 21 pixels. testString: assert($('h5').css('font-size') == '21px'); - text: Your code should set the font-size property for the h6 tag to 14 pixels.  testString: assert($('h6').css('font-size') == '14px');   testString: const regex = /h6s*{s*font-sizes*:s*14pxs*(;s*}|})/i; assert.strictEqual(true, regex.test(code));  ```


Question: Is your feature request related to a problem? Please describe. I noticed that there is a difference between the headers in and . Describe the solution you'd like Everything else is consistent except for the header. A solution would be to have it consistent throughout. Have it display "Learn to code at home" in both links. On the second line. Additional context Add any other context or screenshots about the feature request here. <img width="1095" alt="without home" src="https://user-"<img width="1093" alt="with home" src="https://user-"

<meta content='https://cdn.freecodecamp.org/platform/universal/fcc-twitter-1120X600-social-green.png' name='twitter:image:src' /> <meta content='freeCodeCamp.org' name='twitter:title' /> <del> <meta content='Learn to code. Build projects. Earn certifications.' </del> <ins> <meta content='Learn to code at home. Build projects. Earn certifications.' </ins> + 'Since 2015, 40,000 graduates have gotten jobs at tech ' + 'companies including Google, Apple, Amazon, and Microsoft.' name='twitter:description' />


Question: Is your feature request related to a problem? Please describe. I noticed that there is a difference between the headers in and . Describe the solution you'd like Everything else is consistent except for the header. A solution would be to have it consistent throughout. Have it display "Learn to code at home" in both links. On the second line. Additional context Add any other context or screenshots about the feature request here. <img width="1095" alt="without home" src="https://user-"<img width="1093" alt="with home" src="https://user-"

<script src="https://unpkg.com/docsify-pagination/dist/docsify-pagination.min.js"></script> <script src="https://unpkg.com/docsify-remote-markdown/dist/docsify-remote-markdown.min.js"></script> <del> </html> </del>  No newline at end of file <ins> </html> </ins>


Question: Is your feature request related to a problem? Please describe. The activities count on the search bar in both /learn, and /news is different than /forum. Describe the solution you'd like A clear and concise description of what you want to happen. Fix the count on activities. Additional context Add any other context or screenshots about the feature request here. <img width="629" alt="Screen Shot 2020-05-11 at 23 27 55" src="https://user-"<img width="730" alt="Screen Shot 2020-05-11 at 23 27 39" src="https://user-"

return res.redirect('/forgot'); } res.render('account/reset', { <del> title: 'Password Reset' </del> <ins> title: 'Password Reset', token: req.params.token </ins> }); }); };


Question: Is your feature request related to a problem? Please describe. The activities count on the search bar in both /learn, and /news is different than /forum. Describe the solution you'd like A clear and concise description of what you want to happen. Fix the count on activities. Additional context Add any other context or screenshots about the feature request here. <img width="629" alt="Screen Shot 2020-05-11 at 23 27 55" src="https://user-"<img width="730" alt="Screen Shot 2020-05-11 at 23 27 39" src="https://user-"

from: 'Team@freecodecamp.com', subject: 'Reset your Free Code Camp password', text: [ <del> 'You are receiving this email because you (or someone else)', </del> <ins> 'You are receiving this email because you (or someone else)n', </ins> 'requested we reset your Free Code Camp account's password.nn', <del> 'Please click on the following link, or paste this into your', </del> <ins> 'Please click on the following link, or paste this into yourn', </ins> 'browser to complete the process:nn', 'http://', req.headers.host, '/reset/', token, 'nn', <del> 'If you did not request this, please ignore this email and', </del> <ins> 'If you did not request this, please ignore this email andn', </ins> 'your password will remain unchanged.n' <del> ].join(' ') </del> <ins> ].join('') </ins> }; transporter.sendMail(mailOptions, function(err) { if (err) { return done(err); }


Question: Is your feature request related to a problem? Please describe. The activities count on the search bar in both /learn, and /news is different than /forum. Describe the solution you'd like A clear and concise description of what you want to happen. Fix the count on activities. Additional context Add any other context or screenshots about the feature request here. <img width="629" alt="Screen Shot 2020-05-11 at 23 27 55" src="https://user-"<img width="730" alt="Screen Shot 2020-05-11 at 23 27 39" src="https://user-"

extends ../layout block content <del> .col-sm-8.col-sm-offset-2 form(method='POST') legend Reset Password </del> <ins> .col-sm-8.col-sm-offset-2.jumbotron form(action='/reset/#{token}', method='POST') h1 Reset Password </ins> input(type='hidden', name='_csrf', value=_csrf) .form-group label(for='password') New Password


Question: Describe your problem and how to reproduce it: Not Major: The sentence grammar should read: What type of HTTP request is usually used to access a website? Currently reads: What type of HTTP is request is usually used to access a website? Add a Link to the page with the problem:

```yml question: <del> text: 'What type of HTTP is request is usually used to access a website?' </del> <ins> text: 'What type of HTTP request is usually used to access a website?' </ins> answers: - 'POST' - 'GET'


Question:
In the challenge, the following line tells users to use and , but the tests do not force the user to use and . Since this is an algorithm challenge, I believe we should let the users write the code any way that solves the problem. My suggestion is to change the line's text to the following: Any thoughts?
I'll try to solve problem
Before creating a PR, let's wait for feedback from at least one of the users I tagged.
sure, that sounds like a good idea, especially since we're not testing for those methods.
I think this sounds like a good improvement
ok
Go for it.
Nice, I'm thinking use on the testString, but I first want to know what's the asset version used on this repository. If you want that I use other way, please tell me. I also want to learn more about JavaScript
Or use keyword?
Hello , There should be no need for either of those. The idea is to change the wording of this line of text: Use the array methods slice and splice to copy each element of the first array into the second array, in order. To this: There is no need to change the tests, as they do not check for the or methods.
Thanks. It's very much easy!

## Description
 You are given two arrays and an index.  Use the array methods slice and splice to copy each element of the first array into the second array, in order.   Copy each element of the first array into the second array, in order.  Begin inserting elements at index n of the second array. Return the resulting array. The input arrays should remain the same after the function runs.


Question:
I think the description of the checkfunds method () is faulty. ! It should be: "A method that accepts an amount as an argument. It returns if the amount is greater than the balance of the budget category and returns otherwise. This method should be used by both the method and method." This is more logical, makes the code simpler and actually works with the tests. Browser Version: Firefox 79 on Ubuntu Linux Operating System: Ubuntu 20.04 LTS
this is genuinely a mistake as how can the amount which needs to be withdrawn be more than the balance in the ledger. amount can only be withdrawn if it is less than the balance in ledger. however there can be a probability that a part of that amount can be deducted from balance but the challenge stated nothing for the same. also the test module asked for a False return value which i think is wrong here in the challenge. !
Hello! Has any resolution to this been implemented? Im not entirely sure what to do about submitting this project because this error still exists. Any help is greatly appreciated!
I don't think so, hasn't changed. It doesn't matter though, design the project as if it was modified the way I suggested and it'll be fine.
Thank you, for opening this. For anyone reading, before a fix: Change this: To this in the file: Can I get a sanity check here? What needs to change on the fCC repl account? I am opening this up to first-timers only Here is the repo: The README description makes sense, but the tests do not, in my opinion. So, the README does not need to change.
Thanks for your patience and for catching this Also, thanks for @ mentioning me, Sorry I didn't see this sooner. My first thought is that we don't need to change the test, but just the README like suggested. It seems like is supposed to be used by the other methods to make sure that there's a sufficient balance before calling or . So in the current test: It makes sense that the first condition is false and the second is true -- you shouldn't be able to buy 10. It's just that the current instructions in the README doesn't reflect that. is that what you were thinking for the method? Also, to answer your question once we decide what to do here and fix things in the boilerplate repo, someone on the team can sign into and mirror those changes.
Thanks for that. I was thinking about the use of the method in an odd way.
I'm willing to work on this one if it's agreed that the README needs to be changed instead of the test.
Thanks, for your eagerness and patience. I was a bit quick with approving the change to be made. So, right now, I suggest you leave your current PR open as is. Once we come to a consensus here, we will be sure to let you know which changes (if any) to make on your PR.
no problem. I think it could work the other way around, we would just need to change the description a bit more and maybe change the method name to something like . I heard back from and he agrees that changing the README makes the most sense. The wording that suggested sounds good to me.
Just mirrored the changes from PR in the project: Thanks again everyone for your suggestions, reviews, and for this fix.

{ <del> "node": true </del> <ins> /* * ENVIRONMENTS * ================= */ // Define globals exposed by Node.js. "node": true, /* * ENFORCING OPTIONS * ================= */ // Force all variable names to use either camelCase style or UPPER_CASE // with underscores. "camelcase": true, // Prohibit use of == and != in favor of === and !==. "eqeqeq": true, // Suppress warnings about == null comparisons. "eqnull": true, // Enforce tab width of 2 spaces. "indent": 2, // Prohibit use of a variable before it is defined. "latedef": true, // Require capitalized names for constructor functions. "newcap": true, // Enforce use of single quotation marks for strings. "quotmark": "single", // Prohibit trailing whitespace. "trailing": true, // Prohibit use of explicitly undeclared variables. "undef": true, // Warn when variables are defined but never used. "unused": true, // Enforce line length to 80 characters "maxlen": 80 </ins> }