source-academy / frontend Goto Github PK

It would be good to have our services authenticated by IVLE.

One way to go about doing this is to have the frontend call a URL from IVLE to get a session token. This token can then be stored in the state and used to verify whether a user is logged in.

...or if prettier has SCSS support we should enable that.

Some functions cannot be supported by the system. They are math_log, math_exp, math_random, math_floor, math_sin and math_cos, which are under subtitle Names in the Source §1 specifications.

The only stateless part is the cards, and we end up having 3 REPL containers. In addition, I would like to use a stateful component's methods to fix #41.

It's really bulky.

Probably part of RTTC.

Refer to review on #27.

Suggestion: Add a background color to the html tag.

In accordance with the guide, and more importantly, cleaner code.

#35 (review)

• In src/sagas/index.ts, remove unnecessary yield undefined.

Normal size --> Scale down text --> Icon only --> Stack icons

Source: https://netbasal.com/getting-to-know-the-partial-type-in-typescript-ecfcfbc87cb6

This will allow us to conform to the Redux principle https://redux.js.org/introduction/three-principles#state-is-read-only

Should be pretty straightforward, but I'm adding it here in case we forget.

As of now, they are cols and thus do not stick together when there are size changes.

Typically seen in large lists that are not truncated (size <= 100), the sequence of brackets are not wrapped in the output, causing an overflow.

Currently, violations of Source §1 typing are not leading to error messages. Examples:

> "a" < 1;
false
> true && 1; // this one is particularly tricky
1 
> - false;
0
> - true;
-1
> !0;
true
> -"asdf";
NaN
> 1 * "asdf";
NaN

I was studying the organization of sourceadacemy's menus and realised that despite the 3-tier navigation, my friends and I did not use most of the pages (e.g inbox). This is what it looks like now:

I believe that using just one navigation bar, we can extract the important parts of each section, like so (I have yet to add things like paths and contests). Semantic differentiation can easily be done using delimiters (like the one beside the Device button).

States, that are ultimately part of IState, should be defined in one folder (similar to how source-academy-2 defined Shape).

...and possibly rename it as device.

as the subject says: Source §1

Probably just put it on the left together with the editor run button.

This is the documentation for this rule (and why it is recommended: https://palantir.github.io/tslint/rules/interface-over-type-literal/

To give more context, here is another rule that we also follow: https://palantir.github.io/tslint/rules/interface-name/

I believe that we should keep interface-name as it is useful to distinguish between classes/types and interfaces and we should disable interface-over-type-literal.

This is because semantically, we often want to define a type that is not meant to be extended. An example is CodeOutput in commit 50f04bf, where I have disabled this rule. If I were to not disable it, we would have to end up making it an Interface instead. This would then be required to be named with a prefixed 'I', ICodeOutput. This is confusing, and if extension is really required, we can always make it an Interface willingly.

Not essential yet (as there is only 1 library), but can be worked on together with/after Source §2 (#18)

I saw this neat library on the react-redux-typescript-guide.
Current definition: of an ActionCreator :
export const updateEditorValue: ActionCreator<IUpdateEditorValue> = (newEditorValue: string) => ({ type: UPDATE_EDITOR_VALUE, payload: newEditorValue })
It could possibly be:
export const updateEditorValue: ActionCreator<IUpdateEditorValue> = createStandardAction(UPDATE_EDITOR_VALUE)<string>().

I am still unsure if the usage of https://github.com/piotrwitek/typesafe-actions#3-most-flexible-with-all-helpers is required, but createStandardAction seems to work fine for basic actions. However, more complicated actions (e.g returning a more complex type as a payload) is much more easily done without this library.

...to be implemented.

Changes compared to Source §1:

• the empty list: []
• list library

(that's all)

source_2.pdf

We should abandon the current custom Webpack configuration and simply use react-script-ts.

We missed this in #50.

For now, we should focus on the playground.

these two variables should be defined and assigned to the right values

Refactoring of sagas/index.ts would be required, as some definitions shift (takeEvery from redux-saga/effects to redux-saga) and some type definitions change upon shifting to a later version.

"Blueprint 2.0 introduced SVG icon support and moved icon resources to a separate @blueprintjs/icons package. The Icon component now renders SVG paths and the icon classes are no longer used by any Blueprint React component. Icon font support has been preserved but should be considered a legacy feature that will be removed in a future major version." -- source

We should also take this change to review if any of the icons need to be changed. In particular, the chapter select arrow (?) currently does not render.

Functions such as genericButton are used multiple times, and I think the notifications file should not be kept in the root directory. We could make a src/utils folder to house these.

Seems much cleaner and versatile than a button, but we'll have to see how challenging the implementation is

• yarn start should not open a new browser every time
• yarn start should not complain about files in ./coverage (generated by jest's coverage command)

/home/ning/github/cadet-frontend/coverage/lcov-report/prettify.js
(1,3681): Forbidden bitwise operation

This prevents semantic issues such as having a props interface IIDEProps in #21/layout-slider. In the future we should avoid naming classes/components with acronyms.

We'll address this once IDE is not as actively developed, as there are many PRs that rely on the IDE component.

This would remove the need to use Pick<Props, "prop1"> & Pick<Props, "prop2">. What's left is to see if the checking remains as strict.

W.R.T 83f46be.

We're not sure how the token should be handled in our application. How crucial is the token, in terms of security? Is there some obfuscation that needs to be done?

#29 (review)

• In src/slang/utils/__tests__/rttc.ts, test that the error is instance of TypeError.

All bitwise operations returned undefined.

Currently:

If the container pertains to a particular slice of the state, I believe that we can use that part only in mapStateToProps.

Classes such as the Repl output are not used anywhere but in the file they are defined in.

Playground does not actually call any of the actions right now (e.g evaluation of code)