Станислав Шабалин

export function getDocuments<T>(slug: ''): Promise<T[]>;
export function getDocuments<T>(slug: string): Promise<T>;
export function getDocuments<T>(): Promise<T[]>;
export function getDocuments(slug = ''): Promise<unknown> {
	const endpoint = `/documents/${slug}`
	return getPosts(endpoint);
}

ResultType более не нужен.

https://travis-ci.com/
https://bitbucket.org/product/features/pipelines
https://www.jetbrains.com/teamcity
https://docs.gitlab.com/ee/ci/

Вы можете использовать hook от Gatsby useStaticQuery вместо workquery тогда получиться следующее

const WorkQuery = graphql`
  query WP_Posts {
    allWpPost {
      edges {
        post: node {
          id
          title
          slug
          excerpt
          uri
          }
        }
      }
    }
  }
`

const Work = () => {
const query = useStaticQuery()
  return (
      {query.allWpPost.edges.map(({ post }) => (
      <div>
        <Link to={post.slug}>
        <p>{post.title}</p>
        </Link>
        <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
      </div>
      ))}

  )
}
export default Work

https://www.gatsbyjs.com/docs/how-to/querying-data...

так же возможно проблема в наименовании запроса вместо WorkQuery используйте query

- export const WorkQuery = graphql`
  query WP_Posts {
    allWpPost {
      edges {
        post: node {
          id
          title
          slug
          excerpt
          uri
          }
        }
      }
    }
 }
`

- 
+ export const query = graphql`
  query WP_Posts {
    allWpPost {
      edges {
        post: node {
          id
          title
          slug
          excerpt
          uri
          }
        }
      }
    }
 }
`

Согласно документации: https://www.gatsbyjs.com/docs/how-to/querying-data...

https://simpleisbetterthancomplex.com/tutorial/201...

P.S. ничего ж не мешает попробовать на соседней базе

message = re.sub(r':([A-Z\s]*?):', lambda y: unicodedata.lookup(y.group(1)), msg)

from itertools import groupby

test_list = [{'group': 'style', 'name': 'Классика'}, {'group': 'style', 'name': 'Модерн'}, {'group': 'type', 'name': '2-х комнатная квартира'}, {'group': 'style', 'name': 'Модерн'}]

keyfunc = lambda x:x['group']
res = [list(data) for _, data in groupby(sorted(test_list, key=keyfunc), key=keyfunc)]

from itertools import groupby
from operator import itemgetter

data = [
    {'group': 'style', 'name': 'Классика'},
    {'group': 'style', 'name': 'Модерн'},
    {'group': 'type', 'name': '2-х комнатная квартира'}
]

ig = itemgetter('group')

result = [list(group) for key, group in groupby(sorted(data, key=ig), ig)]

from collections import defaultdict

data = [
    {'group': 'style', 'name': 'Классика'},
    {'group': 'style', 'name': 'Модерн'},
    {'group': 'type', 'name': '2-х комнатная квартира'}
]

result = defaultdict(list)

for item in data:
    result[item['group']].append(item)

result = list(result.values())

Если кэширование происходит декоратором, то он ничего не знает ни о каких страницах и их частях, для него кэшируемые данные - это просто строка, возвращаемая функцией. Для кэширования частями используйте тег cache.

Вам нужен context processor.

Если представления разные - вам в любом случае на каждый запрос нужно будет сходить в базу и забрать кверисет. Вы можете зарефакторить это на уровне кода, вынести в миксин, например, но по производительности останется также.
Потому что чтобы отдать данные в шаблон - вам надо сначала получить их из базы (это в общем случае, не считая кеширования и прочего)

Решить вашу задачу может переход на апи + фронт на JS. Тогда можно забрать один раз данные из апихи и переиспользовать на фронте сколько нужно, пока не потребуется обновление. Возможно для вашей задачи вам хватит одно апихи, отдающей json и простого на фронте.

Создайте абстрактную модель, в которой будет содержаться повторяющийся функционал.
Там, где необходимо, наследуйте от нее.

2 варианта:

1. джанго делает все (быстрее и проще)
   
2. джанго делает админку и rest api, react (желательно + ssr) делает всю отрисовку вебморды и общается за данными к джанге по api (но этот как то из пушки по воробьям)
   

У тебя какие-то неочевидные связи. Язык почему-то должен влиять на фронт, IDE должно влиять не препроцессоры. Попахивает дилетантством.

Лучшее, что ты можешь сейчас сделать — это разделить фронт и бэк. Фронт писать на React'е. Нужен SSR — настроить SSR. Хочешь SASS — легко. Минификацию там сделает за тебя webpack или parcel. ES6 в ES5 переведёт babel.

А пихать в джангу какие-то фронтовые кишки — ну это прям фу.

я добавляю .env в гитигнор и делаю env.skeleton (добавляю в гит) где описываю что вобще должно быть в .env.

Если конфигураций много, то удобнее держать их в файлах .py:

dev.config.py # в .gitignore
test.config.py # в .gitignore
config.py # болванка

В виртуальном окружении просто один параметр dev/prod, или аргументом при запуске cron/systemd или как там ты запускаешь.
Если все-же .env, то можно делать аналогично:

dev.env
prod.env

Заполняешь (настраиваешь) болванки непосредственно на сервере при развертывании.