Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
version: 2
updates:
- package-ecosystem: npm
directory: "/examples/react-vite"
schedule:
interval: weekly
open-pull-requests-limit: 5
groups:
dev-deps:
dependency-type: development
update-types: [minor, patch]

- package-ecosystem: npm
directory: "/examples/vanilla-js"
schedule:
interval: weekly
open-pull-requests-limit: 5
groups:
dev-deps:
dependency-type: development
update-types: [minor, patch]

- package-ecosystem: npm
directory: "/examples/angular"
schedule:
interval: weekly
open-pull-requests-limit: 5
groups:
dev-deps:
dependency-type: development
update-types: [minor, patch]

- package-ecosystem: github-actions
directory: "/"
schedule:
interval: weekly
57 changes: 57 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
name: CI

on:
push:
branches: [main]
pull_request:
branches: [main]

permissions:
contents: read

jobs:
example:
name: ${{ matrix.example }}
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
include:
- example: react-vite
dir: examples/react-vite
build: true
- example: vanilla-js
dir: examples/vanilla-js
build: false
- example: angular
dir: examples/angular
build: true

defaults:
run:
working-directory: ${{ matrix.dir }}

steps:
- name: Checkout
uses: actions/checkout@v6

- name: Setup Node 22 LTS
uses: actions/setup-node@v6
with:
node-version: 22

- name: Install
run: npm ci

- name: Lint
run: npm run lint

- name: Typecheck
run: npm run typecheck

- name: Test
run: npm test

- name: Build
if: ${{ matrix.build }}
run: npm run build
36 changes: 36 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# Dependencies
node_modules/
.pnpm-store/

# Build outputs
dist/
build/
.angular/
.vite/
.parcel-cache/
*.tsbuildinfo

# Test outputs
coverage/
.nyc_output/

# Editor / OS
.DS_Store
.idea/
.vscode/*
!.vscode/extensions.json
*.log
*.swp

# Env files (never commit credentials)
.env
.env.local
.env.*.local

# Cache
.npm/
.eslintcache

# Local-only experiments
tmp/
scratch/
140 changes: 61 additions & 79 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,102 +1,84 @@
*This is a suggested `CONTRIBUTING.md` file template for use by open sourced Salesforce projects. The main goal of this file is to make clear the intents and expectations that end-users may have regarding this project and how/if to engage with it. Adjust as needed (especially look for `{project_slug}` which refers to the org and repo name of your project) and remove this paragraph before committing to your repo.*
# Contributing

# Contributing Guide For {NAME OF PROJECT}
Thanks for your interest in the Salesforce Analytics Embedding SDK example apps.

This page lists the operational governance model of this project, as well as the recommendations and requirements for how to best contribute to {PROJECT}. We strive to obey these as best as possible. As always, thanks for contributing – we hope these guidelines make it easier and shed some light on our approach and processes.
## Governance: published, not actively supported

# Governance Model
> Pick the most appropriate one
This repository is published because the example apps contain useful, canonical
patterns for embedding Tableau Next analytics that we want to share with the
community. It is **not** an actively-staffed product. We do occasional
maintenance — keeping the examples building against current SDK and framework
releases — but we are not soliciting feature contributions and may be slow to
respond to issues and pull requests.

## Community Based
That said, fixes that keep the examples correct and runnable are welcome.

The intent and goal of open sourcing this project is to increase the contributor and user base. The governance model is one where new project leads (`admins`) will be added to the project based on their contributions and efforts, a so-called "do-acracy" or "meritocracy" similar to that used by all Apache Software Foundation projects.
## Good contributions

> or
- **Bug fixes** where an example doesn't build, lint, typecheck, or run.
- **Doc corrections** where the README, `llms.txt`, or inline comments are wrong
or out of date relative to the code.
- **Dependency / compatibility fixes** when a new React, Angular, Vite, or SDK
release breaks an example.
- **Cross-example consistency fixes** — all three examples are meant to mirror
the same scenarios; a change to one often implies the same change to the
others.

## Salesforce Sponsored
## Less likely to be accepted

The intent and goal of open sourcing this project is to increase the contributor and user base. However, only Salesforce employees will be given `admin` rights and will be the final arbitrars of what contributions are accepted or not.
- New frameworks or new example apps (the three here are intentional and
scoped).
- New scenarios beyond the current set (Showcase, Agent, Apply Filter, in-app
config, recoverable error UX).
- Restyling or design-system additions — the examples ship deliberately minimal,
replaceable baseline styles.

> or
If you're unsure whether a change fits, open an issue first rather than
investing time in a large pull request.

## Published but not supported
## Before you open a pull request

The intent and goal of open sourcing this project is because it may contain useful or interesting code/concepts that we wish to share with the larger open source community. Although occasional work may be done on it, we will not be looking for or soliciting contributions.
Each example is standalone. From the example's directory
(`examples/react-vite`, `examples/vanilla-js`, or `examples/angular`):

# Getting started
```bash
npm ci # reproducible install from the committed package-lock.json
npm run lint
npm run typecheck
npm test
npm run build # react-vite and angular only; vanilla-js has no build step
```

Please join the community on {Here list Slack channels, Email lists, Glitter, Discord, etc... links}. Also please make sure to take a look at the project [roadmap](ROADMAP.md) to see where are headed.
These are the same checks CI runs (see `.github/workflows/ci.yml`). A pull
request that doesn't pass them won't be merged.

# Issues, requests & ideas
Each example commits its `package-lock.json`. If you change dependencies, run
`npm install` to update the lock file and commit it alongside your change.
Keep changes small and focused — if you change behavior in one example, apply
the equivalent change to the others so they stay in sync.

Use GitHub Issues page to submit issues, enhancement requests and discuss ideas.
## Reporting issues

### Bug Reports and Fixes
- If you find a bug, please search for it in the [Issues](https://github.com/{project_slug}/issues), and if it isn't already tracked,
[create a new issue](https://github.com/{project_slug}/issues/new). Fill out the "Bug Report" section of the issue template. Even if an Issue is closed, feel free to comment and add details, it will still
be reviewed.
- Issues that have already been identified as a bug (note: able to reproduce) will be labelled `bug`.
- If you'd like to submit a fix for a bug, [send a Pull Request](#creating_a_pull_request) and mention the Issue number.
- Include tests that isolate the bug and verifies that it was fixed.
Use [GitHub Issues](https://github.com/salesforce/analytics-embedding-example-apps-and-auth/issues)
for bugs and questions. Please include the example (React / Vanilla / Angular),
your Node version, and steps to reproduce.

### New Features
- If you'd like to add new functionality to this project, describe the problem you want to solve in a [new Issue](https://github.com/{project_slug}/issues/new).
- Issues that have been identified as a feature request will be labelled `enhancement`.
- If you'd like to implement the new feature, please wait for feedback from the project
maintainers before spending too much time writing the code. In some cases, `enhancement`s may
not align well with the project objectives at the time.
Do **not** file security issues as public GitHub issues — see
[SECURITY.md](SECURITY.md).

### Tests, Documentation, Miscellaneous
- If you'd like to improve the tests, you want to make the documentation clearer, you have an
alternative implementation of something that may have advantages over the way its currently
done, or you have any other change, we would be happy to hear about it!
- If its a trivial change, go ahead and [send a Pull Request](#creating_a_pull_request) with the changes you have in mind.
- If not, [open an Issue](https://github.com/{project_slug}/issues/new) to discuss the idea first.
## Contributor License Agreement (CLA)

If you're new to our project and looking for some way to make your first contribution, look for
Issues labelled `good first contribution`.
All external contributions require a signed Salesforce CLA. You only need to
sign once to contribute to any Salesforce open-source project. You'll be
prompted automatically when you open your first pull request, or you can sign
ahead of time at <https://cla.salesforce.com/sign-cla>.

# Contribution Checklist
## Code of Conduct

- [x] Clean, simple, well styled code
- [x] Commits should be atomic and messages must be descriptive. Related issues should be mentioned by Issue number.
- [x] Comments
- Module-level & function-level comments.
- Comments on complex blocks of code or algorithms (include references to sources).
- [x] Tests
- The test suite, if provided, must be complete and pass
- Increase code coverage, not versa.
- Use any of our testkits that contains a bunch of testing facilities you would need. For example: `import com.salesforce.op.test._` and borrow inspiration from existing tests.
- [x] Dependencies
- Minimize number of dependencies.
- Prefer Apache 2.0, BSD3, MIT, ISC and MPL licenses.
- [x] Reviews
- Changes must be approved via peer code review
Participation in this project is governed by the
[Salesforce Open Source Community Code of Conduct](CODE_OF_CONDUCT.md).

# Creating a Pull Request
## License

1. **Ensure the bug/feature was not already reported** by searching on GitHub under Issues. If none exists, create a new issue so that other contributors can keep track of what you are trying to add/fix and offer suggestions (or let you know if there is already an effort in progress).
2. **Clone** the forked repo to your machine.
3. **Create** a new branch to contain your work (e.g. `git br fix-issue-11`)
4. **Commit** changes to your own branch.
5. **Push** your work back up to your fork. (e.g. `git push fix-issue-11`)
6. **Submit** a Pull Request against the `main` branch and refer to the issue(s) you are fixing. Try not to pollute your pull request with unintended changes. Keep it simple and small.
7. **Sign** the Salesforce CLA (you will be prompted to do so when submitting the Pull Request)

> **NOTE**: Be sure to [sync your fork](https://help.github.com/articles/syncing-a-fork/) before making a pull request.

# Contributor License Agreement ("CLA")
In order to accept your pull request, we need you to submit a CLA. You only need
to do this once to work on any of Salesforce's open source projects.

Complete your CLA here: <https://cla.salesforce.com/sign-cla>

# Issues
We use GitHub issues to track public bugs. Please ensure your description is
clear and has sufficient instructions to be able to reproduce the issue.

# Code of Conduct
Please follow our [Code of Conduct](CODE_OF_CONDUCT.md).

# License
By contributing your code, you agree to license your contribution under the terms of our project [LICENSE](LICENSE.txt) and to sign the [Salesforce CLA](https://cla.salesforce.com/sign-cla)
By contributing, you agree that your contributions will be licensed under the
[Apache License 2.0](LICENSE.txt) that covers this project.
Loading