Fix/empty state handling #13
Merged
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
This commit addresses several potential bugs related to how the application handles scenarios where topics or languages within a topic might be empty.
Previously, the application could crash or behave unexpectedly if:
- No topics were available.
- A selected topic contained no languages.
Changes made:
- Modified `CodeComparison.Languages.get_language/2` to return a default empty `Language` struct when the provided list of languages is empty. This prevents errors when trying to access properties of a non-existent language.
- Updated `CodeComparisonWeb.HomeLive.mount/3` to:
- Handle cases where `Topics.get_topics/0` returns an empty list, by setting default empty values for topic and language assigns.
- Ensure `language1` and `language2` are set to default `Language` structs if the initially selected topic has no languages.
- Updated `CodeComparisonWeb.HomeLive.handle_event/3` (for topic updates) to correctly use the modified `Languages.get_language/2`, ensuring that `language1` and `language2` become default empty structs if a newly selected topic has no languages.
- Enhanced `lib/code_comparison_web/live/home_live.html.leex` to:
- Display "No topics available" if the topics list is empty.
- Display "No languages available" and disable selectors if the current topic has no languages.
- Conditionally render commit information and code blocks, showing placeholder text (e.g., "No code to display") if language data is incomplete or missing.
- Added comprehensive tests:
- A unit test for `Languages.get_language/2` to verify its behavior with empty input.
- LiveView tests for `HomeLive` to cover scenarios such as:
- Mounting with no topics.
- Mounting when the initial topic has no languages.
- Changing to a topic that has no languages.
- Introduced behaviours (`CodeComparison.Topics.Behaviour`, `CodeComparison.Languages.Behaviour`) and Mox mocks to facilitate robust testing independent of the file system.
These changes improve the application's resilience and provide a more user-friendly experience when content is missing.
…ctory is accessible when your application runs on Render:
This update addresses an issue where the application would crash on Render because it couldn't find the `topics/` directory. The error indicated a problem accessing `/code_comparison/topics`.
Here are the key changes:
1. **Dockerfile Update**:
- I modified your `Dockerfile` to include `COPY . .`. This ensures all your application files, including the `topics/` directory, are copied into the Docker image. This makes the directory available in the containerized environment on Render.
- I also set `WORKDIR /code_comparison` and other production defaults in the `Dockerfile`.
2. **Dynamic Path Construction**:
- I've updated the `CodeComparison.Topics` and `CodeComparison.Languages` modules. Now, they construct paths to the `topics/` directory at runtime using `Path.join(Application.app_dir(:code_comparison), "topics")`. This makes accessing files more robust and independent of the absolute working directory, as long as the `topics` directory is present at the application root within the container.
- I've added error handling for file operations to prevent crashes if a directory or file is unexpectedly missing. Instead of crashing, errors will now be logged.
3. **Documentation**:
- I've added a "Deployment Notes" section to your `README.md`. This section explains the importance of the `topics/` directory and how its inclusion and access are handled for deployment.
I wasn't able to directly test these changes within Docker due to limitations in the CI environment. However, the changes are based on standard practices for Dockerizing Elixir applications and managing paths.
**Fix: Provide build-time SECRET_KEY_BASE for Docker builds**
This update resolves an issue where Docker builds were failing. This happened because the `SECRET_KEY_BASE` environment variable wasn't set when `MIX_ENV=prod`, which prevented `mix deps.compile` (and then `mix compile`) from succeeding.
Here are the details of the changes:
1. **Dockerfile Modification**:
- I added an `ENV SECRET_KEY_BASE="..."` line in the `Dockerfile` before any Elixir compilation steps. This sets a temporary, placeholder secret that's good enough for the build process. I made sure the key is long enough to satisfy Phoenix's requirements.
2. **Documentation**:
- I updated the `README.md` in the "Deployment Notes" section. It now explains how `SECRET_KEY_BASE` is managed: a placeholder key is used during the build, and it's important for you to provide a strong, unique key through environment variables when you deploy (for example, in Render).
This adjustment ensures that the Docker image can be built successfully when `MIX_ENV=prod` is set. This allows compilation tasks that rely on `SECRET_KEY_BASE` to finish. You will still need to provide the actual runtime `SECRET_KEY_BASE` through your deployment environment.
This commit addresses an error in the GitHub Actions CI workflow where
`docker-compose: command not found` would occur. The `ubuntu-latest`
runner does not include `docker-compose` by default.
Changes:
- Modified `.github/workflows/elixir.yml`:
- Added a new step "Set up Docker Compose" in the `test` job.
- This step runs `sudo apt-get update` and then
`sudo apt-get install -y docker-compose` to make the
`docker-compose` command available in the CI environment
before it is used by subsequent steps.
Lgdev07
force-pushed
the
fix/empty-state-handling
branch
10 times, most recently
from
cace2d3 to
efc201d
Compare
Lgdev07
force-pushed
the
fix/empty-state-handling
branch
from
efc201d to
d3d9c76
Compare
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.
No description provided.