Instead of getting data out of redux just to pass it back to a dispatch,
use getState in the thunk to get the data we need. This allows the
component to not care about admin/token info, since it is not related
to rendering.
Insteaad of passing in the studio id and user data into the component
just to have it used for fetching data, get that data directly from
the redux store from within the thunk. This simplifies the components
and lets them be concerned more with what they render.
async.auto / async.waterfall now take the callback as the last argument in functions with dependencies.
Async is modularized so eachLimit can be required specifically
This fixes an issue where you could get logged out but then remain on your page by dismissing the window.onbeforeunload prompt when you have unsaved changes. That would put you in a state where you looked logged in but could not save.
Follow up the project info request with a request to the visibility endpoint to find out if the project is trashed or censored. The project just not being published is handled by the existing code.
This PR generalizes the ShareBanner to a more generic "Banner" that is then filled with the relevant content.
This visually appears like a "load more comments" button for now, but has the impact of unsetting the #comments-<id> hash in the url and resetting the comment state, showing all the comments (in paginated view)
This makes a couple of assumptions about the shape of the endpoint:
- Route is /proxy/projects/:id/share.
- Returns the full (updated) project info on success, just like the project update endpoint does.
I reviewed these with colby since this is frontrunning the actual API, but I can update once the API is finalized.
Show the load more comments button any time the last comment page was filled to the requested limit. As noted in the comment, this heuristic will be wrong at most 5% of the time but the failure mode (showing load more which, when clicked doesn't load any more, just goes away) is very mild, and for the overwhelming majority of project views that happen on projects with many, many comments, this is very unlikely to ever be noticed. It obviously isn't a perfect solution, but I cannot think of another that does not need the server to do another query to find out the total number of visible comments, or to find out if there are more comments after the requested offset+limit.
* add canSaveNew prop to pass to GUI
* pass to and receive from GUI info about project lifecycle
* reset project data or fetch new project data depending on updates received from gui
* removed canSaveNew
* projectId always a string
* moved handleUpdateProjectId calls that fetch or set project metadata into componentDidUpdate
* changed page history object
* removed comments
* two small fixes to deal with edge cases
* cleaning up getExtensions
* move login/registration functions and view state to session reducer, pass to gui
* navigation reducer handles login; gui passed renderLogin function
* put back in join class to make smoke tests keep working
* Create Comment component, start styling it
* Restructure PreviewPresentation to better match mockup
* Add padding, border to comment bubble
* add padding to bottom row of comment
* Tweak alignment of avatar and comment content
* Add margin to lower project page container
* Use border-box box sizing for comment bubble
* Make user avatar a link
* Add initial implementation of comment tail
* Align username row properly, fix comment bubble width
* Use ::before pseudoelement for comment tail
* Remove unused props to Comment component
* Add CommentContainer to handle comment replies
* Use CommentContainer instead of Comment in PreviewPresentation
* Remove debug data from CommentContainer
* Fetch top level comments from the API
* Force comment container to stretch to bottom of view div
* Remove unused api import in CommentContainer
* Long words in comments should not overflow page
* Remove @ before username in comment title
* Fix word wrapping on Firefox
* Refactor CommentContainer into a class
* Properly export CommentContainer component
* Make replies column take up proper width
* Pass project ID to CommentContainer
* Fetch comment replies in CommentContainer
* Initial implementation for loading more comments
* Add "Load More" button to Presentation
* Initial implementation of collapsing threads longer than 3 replies
* Remove console log from preview.js redux
* Tweak last comment gradient color
* Only show three total replies in collapsed state
* Match scratchr2 behavior for thread collapsing
* Use width calc instead of margin and width 100%
* Fix styling for load more button
* Make comment border gray to match the wireframe
* Allow clicking through comment fade gradient
* Add comment compose component
* style comment compose box
* Style post, cancel buttons on comment compose component
* Add margin to create comment container
* Tweak styling for characters remaining text
* Tweak placeholder text
* Add more margin to comment avatar
* Add icons and styling to delete, report text
* Refactor px -> rem where possible in comment styles
* Change comment time color to dark gray
* Tweak margin and border radius
* Add reply icon to preview comments
* Clean up unused imports, console.log in compose-comment component
* Remove console statement in preview.jsx
* Add some clarifying comments to unfinished parts of comments
* Remove direct passing of comment api response to CommentContainer
* CommentContainer should not pass api response directly
* Rename CommentContainer to TopLevelComment
* First pass at getReplies for comments in redux
* Move reply fetching into redux actions instead of in TopLevelComment
* Refactor getReplies logic to behave better
* Remove components not directly related to reading comments
* Hide load more button if all comments are loaded
This uses the project info returned by the API
* Use same gradient as add to studio modal on comment thread
First pass at project page design using actual assets from Carl, and matching styles with current design.
Includes a (negative margin) hack to line up the stage. see https://github.com/LLK/scratch-gui/issues/2132
