feat/add viii board #77
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Szymon Kowaliński <szymon@kowalinski.dev> Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com>
* Add docs about building interface in flutter * feat(flutter): shark improvements * feat(flutter): add builder methods antipattern info * feat(flutter): few more rules * fix(flutter): olcia's magic Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com> * feat(flutter): add lifecycle methods * feat(flutter): more info about const constructor * fix(flutter): builder methods reasoning * feat(flutter): add pagination section * Add docs about state management * feat(flutter): shark improvements * fix: apply suggestions from code review / typos Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com> * fix(flutter): olcia's magic hands Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com> * feat(flutter): expand riverpod pros and cons --------- Co-authored-by: Szymon Kowaliński <szymon@kowalinski.dev> Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com>
* Add docs about building interface in flutter * feat(flutter): shark improvements * feat(flutter): add builder methods antipattern info * feat(flutter): few more rules * fix(flutter): olcia's magic Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com> * feat(flutter): add lifecycle methods * feat(flutter): more info about const constructor * fix(flutter): builder methods reasoning * feat(flutter): add pagination section * Add docs about state management * feat(flutter): shark improvements * fix: apply suggestions from code review / typos Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com> * fix(flutter): olcia's magic hands Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com> * feat(flutter): expand riverpod pros and cons * feat(flutter): add simple codegen mention * fix: apply suggestions from code review Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com> * fix(flutter): olcia's magic hands and sight Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com> * feat(flutter): add cons --------- Co-authored-by: Olcia <132699843+odominiak@users.noreply.github.com>
one that actually doesnt require a whole fucking web browser to render a stupid svg
Co-authored-by: karolwolek <karolwolek06@gmail.com>
|
to niezła pr'ka Wojciu 😭 |
|
oho no to sobie rebasenąłem ładnie ;-; |
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to efa86f9 in 3 minutes and 53 seconds. Click for details.
- Reviewed
5395lines of code in25files - Skipped
13files when reviewing. - Skipped posting
22draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. src/components/Mermaid.astro:62
- Draft comment:
In the rerender() method, you manually loop through child nodes (lines 62–66) to remove stale nodes. Consider simplifying cleanup by setting this.innerHTML = '' before appending the new div, if no other content or event listeners need preserving. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The suggestion seems reasonable at first glance - innerHTML = '' would be simpler. However, the current approach is more precise and explicit about what it's doing. The code specifically preserves the newly added div while removing everything else, which innerHTML = '' wouldn't do. The current approach might actually be preferable for clarity and control. The current code might be more intentional than it appears - it ensures the new div stays while everything else is removed. Using innerHTML = '' would require re-appending the div. The existing code is actually more precise and maintains better control over the DOM operations. The suggested change would require additional steps and might not be clearer. The comment should be deleted as the current implementation is intentional and potentially better than the suggested alternative.
2. src/content/docs/git/0-intro.mdx:12
- Draft comment:
Consider using proper Polish diacritics (e.g. use 'będziemy' instead of 'bedziemy') for consistency and improved readability. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. src/content/docs/git/1-singleplayer.mdx:109
- Draft comment:
The text 'error?????????????' appears to be a placeholder. Verify if this is intentional (to demonstrate an error scenario) or remove/clarify it. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. src/content/docs/sections/Mobile/building-interface-in-flutter.md:21
- Draft comment:
There is a TODO comment for flutter_hooks examples. Consider either adding concrete examples or removing the TODO before finalizing the document. - Reason this comment was not posted:
Comment looked like it was already resolved.
5. src/content/docs/sections/Mobile/state-management.md:70
- Draft comment:
A TODO comment exists for adding multiple examples with Riverpod 2.0. Please ensure this is addressed before final release (either by adding examples or removing the TODO). - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to ensure that a TODO is addressed before the final release. It is not making a specific code suggestion or asking for a specific test to be written. It is more of a reminder or a request for confirmation, which violates the rules.
6. src/plugins/mermaid.ts:10
- Draft comment:
The mermaidRemarkPlugin implementation looks solid. For increased type safety, consider adding explicit type guards before casting nodes to MdHtml, ensuring node.value is available as expected. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The code is using TypeScript's visit utility which provides typed callbacks. The node.value property is already being accessed before the casts without issues, suggesting it exists. The casts seem necessary for the transformation and appear safe given the context. Additional type guards would add verbosity without clear benefit. I could be wrong about the safety of these casts - there might be edge cases where node.value is undefined that aren't obvious from this code. The code is already checking node.lang before casting, and the visit utility provides type safety. The suggestion seems overly cautious given the context. The comment should be deleted as it suggests additional type checking that would add complexity without clear benefit, given the existing type safety measures.
7. src/assets/git/chapter-2/contributing-03.cast:550
- Draft comment:
Typo detected in the new readme.md content: In the disclaimer section, the phrase appears as “NIE STANO… WI ON UTWORU GOTOWEGO”. It seems this is a broken word sequence. Likely it should read “NIE STANOWI UTWORU GOTOWEGO” (i.e. “does not constitute a finished work”). Please fix the wording. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The comment points out what appears to be a word break issue in Polish text. However, looking at the full context, this appears to be an artifact of line wrapping in the terminal display, not an actual issue in the text. The words are likely properly joined in the actual file but just happen to wrap at that point in the display. Terminal line wrapping shouldn't be flagged as a typo. Am I certain this is just display wrapping and not a real typo? I don't speak Polish so I can't be 100% sure. The evidence strongly suggests this is display wrapping - we can see many other similar line breaks in the text block that split words, and they all occur at the same column width. This is a clear pattern of terminal display wrapping rather than actual typos. Delete the comment since it's incorrectly flagging normal terminal line wrapping as a typo.
8. src/assets/git/chapter-2/contributing-04.cast:38
- Draft comment:
The text "Kompresja delt z użyciem do 16 wątków" appears to have a typographical error. "delt" might be intended to be "delta". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a recording of Git's output messages in Polish. "delt" appears to be the correct Polish plural form of "delta". The comment is suggesting to "fix" what is actually correct Polish grammar. We should not try to "correct" properly translated messages in other languages. Could "delt" actually be a typo in the Polish translation that should be fixed? Am I certain about Polish grammar? Even if uncertain about Polish grammar, we should not suggest changes to Git's localized output messages in this PR. That would be out of scope and should be handled through Git's translation process if there are issues. Delete this comment as it incorrectly suggests changing what appears to be proper Polish text in Git's output messages.
9. src/assets/git/chapter-2/contributing-04.cast:247
- Draft comment:
There are informal typos in the output message: "sprawdze, dziemki za kod" likely should be "sprawdzę, dzięki za kod". Please confirm if this is intentional. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a recording file that captures actual terminal interaction between users. The informal spelling appears to be intentional casual communication. The file extension .cast suggests this is a terminal recording meant to capture the actual interaction as it happened. Correcting informal language in a recording of real communication would make the recording less authentic. Perhaps informal language could be confusing for learners or make the content seem unprofessional? Maybe consistency in Polish diacritics is important for accessibility? This is clearly meant to be a recording of authentic communication between users. Changing the actual recorded conversation to be more formal would make the recording less realistic and defeat its purpose. Delete this comment. The informal spelling is part of an authentic terminal recording and should not be "corrected" as it would make the recording less realistic.
10. src/assets/git/chapter-2/history-01.drawio:31
- Draft comment:
Typo found: "ficzer" appears to be a misspelling of "feature". Consider correcting it for consistency. - Reason this comment was not posted:
Comment looked like it was already resolved.
11. src/assets/git/chapter-2/merge-02.cast:62
- Draft comment:
Typographical note: In the commit message '* 7bd9ec7 yoo pierwszy zapis!!!!', the word "yoo" appears unusual. Please confirm if this is intentional or if it should be corrected (for example, to "już"). - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to confirm if a typographical choice in a commit message is intentional. This falls under asking for confirmation of intention, which is against the rules. The comment does not provide a specific code suggestion or ask for a test to be written. Therefore, it should be removed.
12. src/assets/git/chapter-2/merge-02.cast:134
- Draft comment:
Typographical note: The filename 'jakis_skrypt.sh' is used. In Polish, you might consider using the proper diacritic ("jakiś_skrypt.sh") if appropriate. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =20%<= threshold50%The comment is suggesting a typographical change to a filename to include a diacritic. This is a minor suggestion and not related to functionality or correctness of the code. It doesn't ask for a specific code improvement or test, nor does it address a potential issue in the code. Therefore, it seems to be more of an informative comment rather than a necessary code review comment.
13. src/assets/git/chapter-2/merge-02.cast:150
- Draft comment:
Typographical note: The commit message segment 'docs: rozwinieto readm…' appears to split the word "readme" into 'readm' and 'e' due to escape sequences. Please verify that this is formatted as intended. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the author to verify the formatting of a commit message, which is not a specific code suggestion or a request for a test. It falls under the category of asking the author to confirm their intention, which is against the rules.
14. src/assets/git/chapter-2/review-01.cast:249
- Draft comment:
Typographical error: "ommit" should be "commit". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a terminal recording file that captures keystrokes and output. The typo is part of the actual recorded keystrokes showing how the user typed the command. Correcting it would make the recording inaccurate to what actually happened. The typo was immediately corrected by the user in the next line anyway. Maybe the typo could confuse readers trying to follow along with the recording? But then again, seeing real typing mistakes makes it more authentic. The authenticity of showing real human typing, including mistakes, is more valuable than having a perfectly clean recording. The correction is shown immediately after anyway. Delete this comment. The typo is part of the actual terminal recording and correcting it would make the recording less authentic. It's immediately corrected in the next line anyway.
15. src/assets/git/chapter-2/review-02.cast:225
- Draft comment:
Typographical issue in the license text: "PRZYZNANIA JAKICHKOLWI EK PRAW DO UTWORU" appears to be split incorrectly. It should likely read "PRZYZNANIA JAKICHKOLWIEK PRAW DO UTWORU". - Reason this comment was not posted:
Comment looked like it was already resolved.
16. src/content/docs/git/2-multiplayer.mdx:567
- Draft comment:
Typo: "Najwiekszą" should be "Największą" (missing diacritical mark on 'ę'). - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This is a new file being added, so the typo is in changed code. The correction is accurate - it's fixing a missing Polish diacritic. However, this is a very minor spelling issue that doesn't affect functionality or understanding. The comment is technically correct but may not be important enough to warrant a comment. While technically correct, spelling/grammar fixes in documentation are usually considered too minor to comment on unless they significantly impact readability or meaning. The meaning is still clear without the diacritic mark. However, since this is documentation in Polish where diacritical marks are standard and meaningful, maintaining proper Polish spelling could be considered important for professionalism and correctness. While a minor issue, proper spelling in documentation is worth maintaining, especially for non-English languages where diacritical marks carry meaning.
17. src/content/docs/sections/Mobile/building-interface-in-flutter.md:8
- Draft comment:
Typo: The relative pronoun should be singular. Consider changing 'które można (prawie) dowolnie łączyć' to 'który można (prawie) dowolnie łączyć' to match 'każdy element [...] jest widgetem'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the grammar correction is technically correct, this is documentation content rather than code. The meaning is clear either way, and this level of grammar nitpicking doesn't affect functionality or understanding. Documentation changes like this are better handled through direct edits or separate editorial reviews. The grammar issue could potentially affect readability for native Polish speakers. Documentation quality does matter for learning and understanding. While documentation quality matters, this minor grammar issue doesn't significantly impact comprehension and isn't the type of issue that needs to be handled through PR comments. Delete this comment as it's a minor documentation grammar issue that doesn't warrant a PR comment.
18. src/content/docs/sections/Mobile/building-interface-in-flutter.md:237
- Draft comment:
Typographical error: 'znaleść' should be corrected to 'znaleźć'. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While this is a legitimate spelling error, spelling and grammar fixes in documentation are not critical code changes that require PR comments. These kinds of minor text fixes can be handled directly in the PR description or fixed in a follow-up PR. The comment doesn't point out any technical or logical issues. The spelling error could affect readability for Polish speakers. Documentation quality is important. While documentation quality matters, PR comments should focus on substantive technical issues rather than minor text fixes that don't affect functionality. Delete this comment as it only points out a minor spelling error and doesn't highlight any technical issues requiring changes.
19. src/content/docs/sections/Mobile/codegen.md:61
- Draft comment:
Typographical suggestion: In the TODO comment, consider replacing "uzycia" with "użycia" for the proper diacritical mark in Polish. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, TODO comments are temporary by nature and will be replaced when the actual content is added. The file is new, so this is part of initial content. Spelling in TODOs is not critical since they're temporary placeholders. This kind of nitpick on a TODO comment doesn't add meaningful value. The spelling correction is technically accurate and would make the Polish text more correct. It could be argued that maintaining proper language standards is important even in temporary content. However, TODO comments are meant to be temporary reminders and will be removed when the actual content is added. Focusing on spelling in temporary comments is not a valuable use of review time. This comment should be deleted as it focuses on a minor spelling issue in temporary content that will be replaced anyway.
20. src/content/docs/sections/Mobile/state-management.md:58
- Draft comment:
There's a typographical error here: "build_runnera" should likely be "b 10000 uild_runner". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically a typo, it's in documentation written in Polish where "build_runnera" appears to be the genitive case of "build_runner" (adding 'a' to show possession/relation is common in Polish grammar). The word is still perfectly understandable to readers and follows Polish language conventions. I might be wrong about Polish grammar rules. Even if it's grammatically correct in Polish, consistency in technical terms might be more important. Even if it's not strictly correct, this is a minor linguistic detail that doesn't impact understanding or code quality. The meaning is clear in context. This comment should be deleted as it's addressing a minor linguistic detail that doesn't impact understanding, especially in a Polish language context where adding 'a' to foreign terms is common practice.
21. src/content/docs/sections/Mobile/state-management.md:70
- Draft comment:
Typographical error: "mutiple" should be corrected to "multiple". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically a typo, it's in a TODO comment that will be replaced anyway. TODOs are temporary placeholders and spending time fixing typos in them isn't valuable. The typo doesn't affect code functionality or documentation clarity since this line will be completely replaced when the TODO is addressed. The typo could confuse readers of the documentation in the meantime. Also, maintaining high quality even in TODOs sets a good standard. The benefit of fixing this typo is extremely minor compared to the noise it adds to the PR review. TODOs are meant to be temporary and will be replaced entirely. Delete this comment as it points out a trivial issue in temporary placeholder text that will be replaced anyway.
22. src/content/docs/solvro/VIII_Board.mdx:65
- Draft comment:
Lexicographical inconsistency: The text "Bajabongers und leszczyners" here differs from the phrasing used in the other cards (which use "Bajabongo i leszczyny"). Please verify the intended wording. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =50%<= threshold50%The comment points out a potential inconsistency in wording, which could be a real issue if consistency is required. However, it asks the author to verify the intended wording, which is against the rules. The comment could be rephrased to suggest a specific action or change instead of asking for verification.
Workflow ID: wflow_XAkWhTJIc3lsI5Bn
You can customize 
| [33.234254, "o", "\u001b[32m+\u001b[m\u001b[32mZ POWYŻSZYCH WZGLĘDÓW UTWÓRZ PRZEKAZUJE SIĘ NA MOCY LICENCJI W POSTACI, W JAKIEJ JEST UDOSTĘPNIANY,\u001b[m \b\u001b[32m\u001b[m\u001b[32m I BEZ JAKICHKOLWIEK GWARANCJI DOTYCZĄCYCH UTWÓRU, W TYM MIĘDZY INNYMI BEZ GWARANCJI PRZYDATNOŚĆI HA\u001b[m \b\u001b[32m\u001b[m\u001b[32mNDLOWEJ, GWARANCJI PRZYDATNOŚC"] | ||
| [33.234432, "o", "I DO OKREŚLONEGO CELU, GWARANCJI BRAKU WAD I BŁĘDÓW, GWARANCJI DOKŁADN\u001b[m \b\u001b[32m\u001b[m\u001b[32mOŚCI, GWARANCJI BRAKU NARUSZENIA PRAW WŁASNOŚCI INTELEKTUALNEJ INNYCH NIŻ PRAWA AUTORSKIE, O KTÓRYCH\u001b[m \b\u001b[32m\u001b[m\u001b[32m MOWA W PKT 6 NINIEJSZEJ LICENCJI.\u001b[m\u001b[m\r\n\u001b[32m+\u001b[m\u001b[m\r\n\u001b[32m+\u001b[m\u001b[32mNINIEJSZE WYŁĄCZENIE GWARANCJI STANOWI ISTOTNY ELEMENT LICENCJI ORAZ WARUNEK PRZYZNANIA JAKICHKOLWI\u001b[m \b\u001b[32m\u001b[m\u001b[32mEK PRAW DO UTWORU.\u001b[m\u001b[m\r\n:\u001b[K"] | ||
| [34.676109, "o", "\r\u001b[K \u001b[KESC\b\b\bESC\u001b[KO\bO\u001b[KB\bB\r\u001b[K\u001b[32m+\u001b[m\u001b[m\r\n:\u001b[K"] | ||
| [35.008539, "o", "\r\u001b[K \u001b[KESC\b\b\bESC\u001b[KO\bO\u001b[KB\bB\r\u001b[K\u001b[32m+\u001b[m\u001b[32m~ fragment licencji EUPL v1.2 w wersji polskiej\u001b[m\u001b[m\r\n:\u001b[K"] |
There was a problem hiding this comment.
Typographical issue in the license text: the phrase NIE STANO WI ON UTWORU GOTOWEGO should be corrected to NIE STANOWI UTWORU GOTOWEGO.
| Dlatego zamiast tego musisz stworzyć nową gałąź, na której możesz zacząć dokonywać zmiany. | ||
| Stworzyć nową gałąź może być warto nawet jeżeli masz uprawnienia do zapisywania zmian, | ||
| szczególnie jeżeli więcej niż jedna osoba ma takie uprawnienia lub jeżeli tempo developmentu w projekcie jest wysokie. | ||
| Zapisując bezpośrednio na gałąź główno łatwo jest doznać konfliktów, gdzie podczas dokonywania zmian inna osoba opublikowała swoje nowe zapisy na tą samą gałąź. |
There was a problem hiding this comment.
Typo: "główno" should be "główną" in the sentence 'Zapisując bezpośrednio na gałąź główno łatwo jest doznać konfliktów.'
Suggested change
| Zapisując bezpośrednio na gałąź główno łatwo jest doznać konfliktów, gdzie podczas dokonywania zmian inna osoba opublikowała swoje nowe zapisy na tą samą gałąź. | |
| Zapisując bezpośrednio na gałąź główną łatwo jest doznać konfliktów, gdzie podczas dokonywania zmian inna osoba opublikowała swoje nowe zapisy na tą samą gałąź. |
|
|
||
| Odpowiedź na te pytania, tak jak z resztą na kilka poprzednich dotyczących specyfiki używania gita, będą zależały od projektu i osób je prowadzących. | ||
| Niektórzy lubią rozdrabniać swoje zmiany na wiele małych, a innym nie przeszkadza zaimplementowanie czegoś dużego jako jeden, duży zapis. | ||
| Czasami osoby prowadzące projekt intergrują zmiany za pomocą metody "squash" (więcej o niej nieco później) i w sumie to, czy ktoś rozdziela zapisy czy nie |
There was a problem hiding this comment.
Typo: "intergrują" should be "integrują" in '...osoby prowadzące projekt intergrują zmiany za pomocą metody "squash"...'
Suggested change
| Czasami osoby prowadzące projekt intergrują zmiany za pomocą metody "squash" (więcej o niej nieco później) i w sumie to, czy ktoś rozdziela zapisy czy nie | |
| Czasami osoby prowadzące projekt integrują zmiany za pomocą metody "squash" (więcej o niej nieco później) i w sumie to, czy ktoś rozdziela zapisy czy nie |
| <Card title="Rozbijaj duże zmiany na mniejsze" icon="puzzle"> | ||
| Gdy dodajesz jakąś dużą funkcjonalność (wymagającą dodania wielu nowych systemów i/lub ze zmianami w wielu plikach), | ||
| nie łącz całości jako jeden duży zapis. Spróbuj rozbić ją na kilka mniejszych zmian, na przykład na osobne dodane/zmodyfikowane systemy. | ||
| Pamietaj jednak o pierwszej zasadzie. |
There was a problem hiding this comment.
Typo: "Pamietaj" should include the correct diacritical mark – it should be "Pamiętaj".
Suggested change
| Pamietaj jednak o 8000 pierwszej zasadzie. | |
| Pamiętaj jednak o pierwszej zasadzie. |
| - Jeżeli chcesz wszystkie zmiany przydzielić do danego zapisu, użyj prostej komendy `git add <plik>`. | ||
| - Jeżeli chcesz wybrać tylko niektóre zmiany z danego pliku, użyj komendy `git add --patch [plik]`, | ||
| a następnie kolejno wybieraj, odrzucaj lub dziel bloki zmian. | ||
| - Aby podejrzeć, jakie zmainy już wybrałeś, użyj komendy `git diff --staged`. |
There was a problem hiding this comment.
Typo: "zmainy" should be "zmiany" in the phrase 'Aby podejrzeć, jakie zmainy już wybrałeś...'
Suggested change
| - Aby podejrzeć, jakie zmainy już wybrałeś, użyj komendy `git diff --staged`. | |
| - Aby podejrzeć, jakie zmiany już wybrałeś, użyj komendy `git diff --staged`. |
| - Debugowanie może być trudniejsze ze względu na "magiczność" działania. | ||
| - Niektóre zaawansowane funkcje (jak autoDispose, family providers) mogą prowadzić do nieoczekiwanych zachowań jeśli nie są prawidłowo zrozumiane i zastosowane. | ||
|
|
||
| :::note |
There was a problem hiding this comment.
It looks like the admonition block marker has an extra colon. ::::note might be intended to be :::note.
| <p>Bajabongo i leszczyny</p> | ||
| <div class="mt-6 pt-4 flex gap-4 items-center border-t border-white/20"> | ||
| <a | ||
| href="https://solvro.pwr.edu.pl/enwww.linkedin.com/in/micha%C5%82-bocian-b207a1199/" |
There was a problem hiding this comment.
Typographical error: The URL in the Michał Bocian card appears malformed. It reads https://solvro.pwr.edu.pl/enwww linkedin.com/in/micha%C5%82-bocian-b207a1199/ which likely should be corrected (for example, to something like https://www.linkedin.com/in/michał-bocian-b207a1199/).
Suggested change
| href="https://solvro.pwr.edu.pl/enwww.linkedin.com/in/micha%C5%82-bocian-b207a1199/" | |
| href="https://www.linkedin.com/in/micha%C5%82-bocian-b207a1199/" |
|
ide naprawiac pozdro |
|
skaza na moim honorze do końca życia, moved to #78 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Important
Add VIII Board documentation, integrate mermaid for diagrams, and enhance layout and formatting for documentation.
VIII_Board.mdxfor VIII Zarząd documentation.Promotional Process.mdxfor social media promotional guidelines.codegen.mdfor Flutter code generation documentation.2-multiplayer.mdxfor Git multiplayer sandbox documentation.mermaidRemarkPlugininmermaid.tsfor processing mermaid code blocks.Mermaid.astrocomponent for rendering mermaid diagrams.astro.config.mjsto includemermaidRemarkPlugin.mermaiddependency inpackage.json.VIII_Board.mdx.This description was created by
for efa86f9. You can customize this summary. It will automatically update as commits are pushed.