Feature incognito mode #1450
Feature incognito mode #1450
Conversation
flbulgarelli
force-pushed
the
feature-userless-mode
branch
from
2dd3dbd to
c913a12
Compare
flbulgarelli
force-pushed
the
feature-userless-mode
branch
from
331b135 to
45d38a0
Compare
| * This module allows to read and write the current editor's contents | ||
| * regardless if it is an standard editor or a custom editor | ||
| */ | ||
| mumuki.editors = { |
There was a problem hiding this comment.
You will notice that I din't use a module-lambda here, just because it was not necessary. This is a direct consequence of building more cohesive module objects - only one module per file - using ES6 constructs, and clearly separating the initialization code - which is run only once - from the loading - mumuki.load - code - which is loaded on page load and after turbolinks load event.
I think we should tend to favor this construct when just a bunch of related functions are required, since it is less cumbersome.
There was a problem hiding this comment.
Ok, didn't see this one. Never mind my two comments related to the lambda function
flbulgarelli
force-pushed
the
feature-userless-mode
branch
from
50a3d18 to
c1e943f
Compare
|
|
||
| CsrfToken.prototype = { | ||
| newRequest: function (data) { | ||
| mumuki.CsrfToken = (() => { |
There was a problem hiding this comment.
I find this notation still quite cumbersome 😕
Is there any reason not to do something like:
mumuki.CsrfToken = class {
...
}
| * | ||
| * CustomEditor sources are cleared after page reload even when using turbolinks | ||
| */ | ||
| mumuki.CustomEditor = (() => { |
There was a problem hiding this comment.
Same here.
We are defining an anonymous function that creates and object and returns it.
Isn't more straight-forward ¿and produces the same result?
doing:
mumuki.CustomEditor = {
...
}
We would need to change all CustomEditor calls for this and call mumuki.load outside it.
Sorry if you already consider doing this and found out that it's not gonna work!
| @@ -0,0 +1,77 @@ | |||
| /** @type {boolean} */ | |||
app/assets/javascripts/mumuki_laboratory/application/sync-mode.js
Outdated
Show resolved
Hide resolved
| @@ -1,10 +1,14 @@ | |||
| module LocaleHelper | |||
| def locale_tags | |||
| module GlobalsHelper | |||
| @@ -17,7 +17,7 @@ | |||
| <% end %> | |||
| </div> | |||
| <div class="mu-navbar-avatar"> | |||
| <% if current_user? %> | |||
| <% if current_user? && !current_user.incognito? %> | |||
There was a problem hiding this comment.
It's not necessary now but maybe we should refactor a bit this section and move it to a helper to make it incognitable 😛 as well without adding this condition
| @@ -0,0 +1,54 @@ | |||
| describe('editors', () => { | |||
| @@ -0,0 +1,6 @@ | |||
| describe("global loading", () => { | |||
flbulgarelli
force-pushed
the
feature-userless-mode
branch
from
dc92ed7 to
3a6109d
Compare
📝 Details
This PR is mostly client-side, but requires the new
Mumuki::Domain::Incognitouser, that allows to polymorphically deal with a null-user. On the client side, this feature leverages the newmumuki.SubmissionsStorein order to render the progress - both status bar and current exercise content when exercise page is loaded.In addition to such functional changes, there we some code improvements:
pageandeditormodules have been refactorededitorsmodule has been introduced, that makes easier to polimorphically handle standard and custom editors🔙 Backward compatibility
This PR breaks some backward compatibility in the JS side - it changes the submissions API - and therefore this PR is not backwards compatible
🔜 Future work
This PR is inspired in #1434 and thus it does not render progress on non-exercises pages. It may be generalized in the future. This will be related to the #1363 issue and all the server-side progress efforts. Likewise, this PR does neither implement the "next exercise" logic yet, nor a sync-after-login logic